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.
Created attachment 12974 [details]
Test file mentioned in body of report.
Created attachment 12975 [details]
Complete crash log
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?
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.)
(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.
(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?
Sometimes. For that particular web archive, the first load always works here, and it crashes on reload.
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
Created attachment 13003 [details]
Stack trace from crash described in Comment #9
I tried many times and could not reproduce with r19525.
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?
Like mjs and ddkilzer, I was finally able to *not* reproduce the problem.
After that happens, we crash.
Running a debug build yields:
ASSERTION FAILED: m_state == FrameStateProvisional
I don't (yet) have a simpler reduction of the problem. Hopefully the additional information is useful.
Also, the advertisement in question is using Flash.
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.
Jim says he can still reproduce this.
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.
(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
> 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?
Committed revision 20053.