Loading the attached webarchive on a locally-built debug build of WebKit r17937 on Mac OS X 10.4.8 with Safari 2.0.4 (419.3) causes an assertion failure:
ASSERTION FAILED: m_webFrame->_private->currentItem
This failure does not occur on the nightly build of r17937 (which is a release build).
Crash reporter stack:
Date/Time: 2006-11-30 22:45:05.509 -0600
OS Version: 10.4.8 (Build 8L127)
Report Version: 4
Parent: bash 
Version: 2.0.4 (419.3)
Build Version: 1
Project Name: WebBrowser
Source Version: 4190300
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbbadbeef
Thread 0 Crashed:
0 com.apple.WebKit 0x003d6724 WebFrameLoaderClient::restoreScrollPositionAndViewState() + 124 (WebFrameLoaderClient.mm:939)
1 com.apple.WebCore 0x014698a4 WebCore::FrameLoader::checkLoadCompleteForThisFrame() + 1352 (FrameLoaderMac.mm:1020)
2 com.apple.WebCore 0x01493e70 WebCore::FrameLoader::checkLoadComplete() + 204 (FrameLoader.cpp:2150)
3 com.apple.WebCore 0x01496dd0 WebCore::FrameLoader::removeSubresourceLoader(WebCore::ResourceLoader*) + 96 (FrameLoader.cpp:1749)
4 com.apple.WebCore 0x0147502c WebCore::SubresourceLoader::didFinishLoading() + 384 (SubresourceLoaderMac.mm:174)
5 com.apple.WebCore 0x0146f45c -[WebCoreResourceLoaderAsDelegate connectionDidFinishLoading:] + 124 (ResourceLoaderMac.mm:571)
6 com.apple.Foundation 0x9299384c -[NSURLConnection(NSURLConnectionInternal) _sendDidFinishLoadingCallback] + 188
7 com.apple.Foundation 0x92991ab8 -[NSURLConnection(NSURLConnectionInternal) _sendCallbacks] + 556
8 com.apple.Foundation 0x92991810 _sendCallbacks + 156
9 com.apple.CoreFoundation 0x907dd4cc __CFRunLoopDoSources0 + 384
10 com.apple.CoreFoundation 0x907dc9fc __CFRunLoopRun + 452
11 com.apple.CoreFoundation 0x907dc47c CFRunLoopRunSpecific + 268
12 com.apple.HIToolbox 0x93208740 RunCurrentEventLoopInMode + 264
13 com.apple.HIToolbox 0x93207dd4 ReceiveNextEventCommon + 380
14 com.apple.HIToolbox 0x93207c40 BlockUntilNextEventMatchingListInMode + 96
15 com.apple.AppKit 0x9370bae4 _DPSNextEvent + 384
16 com.apple.AppKit 0x9370b7a8 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116
17 com.apple.Safari 0x00006740 0x1000 + 22336
18 com.apple.AppKit 0x93707cec -[NSApplication run] + 472
19 com.apple.AppKit 0x937f887c NSApplicationMain + 452
20 com.apple.Safari 0x0005c77c 0x1000 + 374652
21 com.apple.Safari 0x0005c624 0x1000 + 374308
Created attachment 11702 [details]
Test webarchive (will crash debug builds)
Webarchive file used to reproduce the assertion failure.
Created attachment 12537 [details]
This attachment is a tiny app that demonstrates the crash. It just loads an empty html file, and then when you click reload (attached to -reload:) it will crash. The executable is set to use the webkit from a nightly in /Applications.
According to David Smith, this crashes in release builds.
I can totally repro this using the test app.
I don't have alot of time to look at it at the moment, but this is high on my priority list.
It's quite easy to see from the assertion that it'll crash a release build, as well ;) Every single time!
If this crashes release builds as well, this isn't a regression now is it? :)
(In reply to comment #6)
> If this crashes release builds as well, this isn't a regression now is it? :)
"release builds" in this context means "TOT builds using the release build style", not "shipping builds".
I could not reproduce the bug with the test app, although it's still reproducible with the webarchive.
This regressed in http://trac.webkit.org/projects/webkit/changeset/14920
The attached webarchive doesn't crash nightly r21059 for me. A comment after the failing assertion casts some doubt over its validity:
// FIXME: As the ASSERT attests, it seems we should always have a currentItem here.
// One counterexample is <rdar://problem/4917290>
// For now, to cover this issue in release builds, there is no technical harm to returning
// early and from a user standpoint - as in the above radar - the previous page load failed
// so there *is* no scroll or view state to restore!