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 (/.../WebKit/WebKit/WebCoreSupport/WebFrameLoaderClient.mm:939 restoreScrollPositionAndViewState) 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 Command: Safari Path: /Applications/Safari.app/Contents/MacOS/Safari Parent: bash [442] Version: 2.0.4 (419.3) Build Version: 1 Project Name: WebBrowser Source Version: 4190300 PID: 1990 Thread: 0 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] Test App 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!
<rdar://problem/4940408>
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!