Bug 12634 – REGRESSION: crash loading web archive

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Jim Correia]

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.

[Jim Correia]

Created attachment 12974 [details]
Test file mentioned in body of report.

[Jim Correia]

Created attachment 12975 [details]
Complete crash log

[David Kilzer (:ddkilzer)]

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?

[Jim Correia]

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.)

[Maciej Stachowiak]

<rdar://problem/4981000>

[Jim Correia]

(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.

[David Kilzer (:ddkilzer)]

(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?

[Jim Correia]

Sometimes. For that particular web archive, the first load always works here, and it crashes on reload.

[David Kilzer (:ddkilzer)]

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

[David Kilzer (:ddkilzer)]

Created attachment 13003 [details]
Stack trace from crash described in Comment #9

[Maciej Stachowiak]

I tried many times and could not reproduce with r19525.

[Jim Correia]

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?

[Jim Correia]

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.

[Jim Correia]

Also, the advertisement in question is using Flash.

[Anders Carlsson]

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.

[Anders Carlsson]

Jim says he can still reproduce this.

[Jim Correia]

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.

[David Kilzer (:ddkilzer)]

(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?

[Anders Carlsson]

Committed revision 20053.