Bug 12634 - REGRESSION: crash loading web archive
Summary: REGRESSION: crash loading web archive
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P1 Critical
Assignee: Nobody
URL:
Keywords: InRadar, Regression
Depends on:
Blocks:
 
Reported: 2007-02-06 09:56 PST by Jim Correia
Modified: 2007-03-07 23:29 PST (History)
1 user (show)

See Also:


Attachments
Test file mentioned in body of report. (752.57 KB, application/x-webarchive)
2007-02-06 09:57 PST, Jim Correia
no flags Details
Complete crash log (22.49 KB, text/plain)
2007-02-06 09:58 PST, Jim Correia
no flags Details
Stack trace from crash described in Comment #9 (4.83 KB, text/plain)
2007-02-07 07:39 PST, David Kilzer (:ddkilzer)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Correia 2007-02-06 09:56:33 PST
Load the attached web archive into the nightly build (19418).

After it is done loading, hit reload. 

Crashes with backtrace:

0   com.apple.WebCore              	0x013e21aa WebCore::ResourceRequest::updateResourceRequest() const + 10 (ResourceRequest.cpp:194)
1   com.apple.WebCore              	0x013e2378 WebCore::ResourceRequest::url() const + 18 (ResourceRequest.cpp:50)
2   com.apple.WebCore              	0x013a41b2 WebCore::FrameLoader::commitProvisionalLoad(WTF::PassRefPtr<WebCore::PageCache>) + 348 (FrameLoader.cpp:2302)
3   com.apple.WebCore              	0x013a8027 WebCore::DocumentLoader::commitIfReady() + 71 (PassRefPtr.h:45)
4   com.apple.WebCore              	0x013a8135 WebCore::DocumentLoader::finishedLoading() + 25 (DocumentLoader.cpp:285)
5   com.apple.WebCore              	0x0139c4fb WebCore::FrameLoader::finishedLoading() + 53 (FrameLoader.cpp:2517)
6   com.apple.WebCore              	0x013ab832 WebCore::MainResourceLoader::didFinishLoading() + 34 (MainResourceLoader.cpp:302)
7   com.apple.WebCore              	0x013ac099 WebCore::MainResourceLoader::continueAfterContentPolicy(WebCore::PolicyAction, WebCore::ResourceResponse const&) + 1173 (MainResourceLoader.cpp:235)
8   com.apple.WebCore              	0x013ac18f WebCore::MainResourceLoader::continueAfterContentPolicy(WebCore::PolicyAction) + 107 (MainResourceLoader.cpp:250)
9   com.apple.WebCore              	0x0139b338 WebCore::FrameLoader::continueAfterContentPolicy(WebCore::PolicyAction) + 492 (RefPtr.h:41)
10  com.apple.WebKit               	0x00376fc2 -[WebFramePolicyListener receivedPolicyDecision:] + 56 (RefPtr.h:41)
11  com.apple.WebKit               	0x003740cd -[WebFramePolicyListener use] + 41 (WebFrameLoaderClient.mm:1216)


This works on Safari 2.0.4/419.3 on 10.4.8.
Comment 1 Jim Correia 2007-02-06 09:57:56 PST
Created attachment 12974 [details]
Test file mentioned in body of report.
Comment 2 Jim Correia 2007-02-06 09:58:23 PST
Created attachment 12975 [details]
Complete crash log
Comment 3 David Kilzer (:ddkilzer) 2007-02-06 10:27:38 PST
I can't reproduce this with a local debug build of WebKit r19433 with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037).

Jim, were you connected to the internet when you loaded the webarchive?  Did you get a pop-up when you opened the webarchive, or do you have pop-ups disabled?

Comment 4 Jim Correia 2007-02-06 10:40:54 PST
Yes. I was connected to the internet.

Yes, Safari's popup blocker is enabled. (However, turning it off doesn't seem to avoid the problem.)
Comment 5 Maciej Stachowiak 2007-02-06 23:26:24 PST
<rdar://problem/4981000>
Comment 6 Jim Correia 2007-02-07 05:56:12 PST
(In reply to comment #3)
> I can't reproduce this with a local debug build of WebKit r19433 with Safari
> 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037).

FWIW, I just reproduced this on 10.4.8 (8L2127/Intel) with Safari 2.0.4 running against r19441.
Comment 7 David Kilzer (:ddkilzer) 2007-02-07 06:25:02 PST
(In reply to comment #6)
> FWIW, I just reproduced this on 10.4.8 (8L2127/Intel) with Safari 2.0.4 running
> against r19441.

Jim, does this happen every time you load the webarchive, or just some times?
Comment 8 Jim Correia 2007-02-07 06:31:40 PST
Sometimes. For that particular web archive, the first load always works here, and it crashes on reload.
Comment 9 David Kilzer (:ddkilzer) 2007-02-07 07:38:10 PST
I finally got this to crash after reloading (basically opening the webarchive once, closing its window, doing some other things in Safari+WebKit, and then loading the webarchive in a new window once again).

I still can't get exact steps to reproduce, but I did get it to crash once.  Reproduced using a local debug build of WebKit r19458 with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8L127).  Here is the assertion failure console message:

ASSERTION FAILED: m_state == FrameStateProvisional
(/Users/ddkilzer/Projects/Cocoa/WebKit/WebCore/loader/FrameLoader.cpp:2322 transitionToCommitted)
Segmentation fault
Comment 10 David Kilzer (:ddkilzer) 2007-02-07 07:39:46 PST
Created attachment 13003 [details]
Stack trace from crash described in Comment #9
Comment 11 Maciej Stachowiak 2007-02-09 03:31:45 PST
I tried many times and could not reproduce with r19525.
Comment 12 Jim Correia 2007-02-09 06:29:48 PST
This is still crashing reliably for me here with the stack trace in my original report. (This is different from Dave's stack trace.)

I'm running Safari 2.0.4 against r19528 on 10.4.8 as of this writing. Is there any other information which would help?
Comment 13 Jim Correia 2007-02-09 07:23:25 PST
Like mjs and ddkilzer, I was finally able to *not* reproduce the problem.

Digging into this further, it appears that it happens on a reload if there is an unsafe javascript attempt to access a different frame. This depends on which the current ad rotation is at cnn.com.

When this happens, the following is logged to the console (with javascript exception logging turned on):

Unsafe JavaScript attempt to access frame with URL http://www.cnn.com/ from frame with URL http://ad.doubleclick.net/adi/N3285.cnn/B1872795.20;dcadv=895178;sz=336x280;click=http://ads.cnn.com/event.ng/Type=click&FlightID=38677&AdID=49897&TargetID=913&Segments=730,2259,2725,2743,2813,3030,3285,3506,3549,3800,4960,5516,5854,6298,6520,6582,6810,7049,7051,7203,7303,7324,7373&Targets=913,8450,1515,3297,3392,8112,10403,10705,10880,10885,10920,10983&Values=30,46,50,61,73,82,91,100,110,150,682,685,686,917,972,1285,1557,1588,1601,1647,1669,1691,1722,2677,2732,2746,4413,4418,4441,5401,47181,47456,47739,49553&RawValues=TLD%2C%253F%2CZIP%2C03101&Redirect=;ord=bftsfid,bcNrpkRmxwtcv?. Domains must match.

After that happens, we crash.

Running a debug build yields:

ASSERTION FAILED: m_state == FrameStateProvisional
(/Users/correia/tmp/WebKit/WebCore/loader/FrameLoader.cpp:2330 transitionToCommitted)
Segmentation fault

I don't (yet) have a simpler reduction of the problem. Hopefully the additional information is useful.
Comment 14 Jim Correia 2007-02-09 08:30:52 PST
Also, the advertisement in question is using Flash.
Comment 15 Anders Carlsson 2007-02-19 11:41:09 PST
I can not reproduce this at all, no matter how many times I reload. Also, I don't think the unsafe JS error has anything to do with the crash. 

Closing.
Comment 16 Anders Carlsson 2007-02-19 11:59:06 PST
Jim says he can still reproduce this.
Comment 17 Jim Correia 2007-02-24 09:04:38 PST
I can still reproduce this as of r19837, but don't yet have a 100% reduction of the problem (since it seems to depend what ad CNN.com serves up on a given reload.)

In the debugger I'm seeing that the ASSERT at the top of FrameLoader::transitionToCommitted fails:

ASSERT(m_state == FrameStateProvisional);

m_state is already 1/FrameStateCommittedPage.

If we return (as we would in a release build) we end up in FrameLoader::commitProvisionalLoad with a nil m_provisionalDocumentLoader, which is used anyway, which is end reason for the crash.

I can seem to reproduce this more readily than others, but I'm not an expert on this codebase. I'm happy to do more debugging (how did the FrameLoader get into an unexpected state?) if someone can point me in the right direction.
Comment 18 David Kilzer (:ddkilzer) 2007-02-25 10:18:07 PST
(In reply to comment #17)
> I can still reproduce this as of r19837, but don't yet have a 100% reduction of
> the problem (since it seems to depend what ad CNN.com serves up on a given
> reload.)
>[...]
> I can seem to reproduce this more readily than others, but I'm not an expert on
> this codebase. I'm happy to do more debugging (how did the FrameLoader get into
> an unexpected state?) if someone can point me in the right direction.

The best thing to do is to try to capture the source (*.swf) of an ad that is causing problems, then combine it with the saved page to create a reproducible test case (in HTML).

Do *.swf files normally get preserved in webarchive files?

Comment 19 Anders Carlsson 2007-03-07 23:29:00 PST
Committed revision 20053.