Bug 11731 – REGRESSION: ASSERTION FAILED: m_webFrame->_private->currentItem (WebFrameLoaderClient::restoreScrollPositionAndViewState())

• Status: NEW
• Component: Page Loading

[David Kilzer (:ddkilzer)]

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

[David Kilzer (:ddkilzer)]

Created attachment 11702 [details]
Test webarchive (will crash debug builds)

Webarchive file used to reproduce the assertion failure.

[David Smith]

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.

[Brady Eidson]

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!

[Mark Rowe (bdash)]

<rdar://problem/4940408>

[Joost de Valk (AlthA)]

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.

[Anders Carlsson]

This regressed in http://trac.webkit.org/projects/webkit/changeset/14920 

[Alexey Proskuryakov]

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!