Append an iframe, register a suicidal onload, then set its src to "about:blank". Pretty much the same problem as: LayoutTests/fast/frames/onload-remove-iframe-crash.html Difference is the entry point (here the death gears are set in motion by assigning the iframe.src property) Will follow up with reduced test case (I observed the problem on http://www.hixie.ch/tests/adhoc/dom/level0/location/components/001.html) Repro-ed it in Webkit Nightly (r31381), and Safari 3.1 (Windows XP)
Created attachment 20148 [details] Crash by removing the iframe within its onload handler
See also: bug 15707.
The crash I get with Hixie's site seems like a dupe of 15707. The attached test case does not reproduce for me in Safari 3.1
The reduction *does* seem to cause an ASSERT in a ToT debug build. Unknown if it manifests as a real issue in a release build, however. (as I mentioned, doesn't crash Safari 3.1 for me)
Does not crash for me on latest webkit (35039) either. (test case in question is attachment id=20148) Strange that it doesn't crash your Safari 3.1 though -- I can repro the crash on both winxp and osx. Here is what I get on 10.4: Version: 3.1.1 (4525.18) Build Version: 1 Project Name: WebBrowser Source Version: 45251800 PID: 18378 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0 Crashed: 0 com.apple.WebCore 0x95579a6f WebCore::Frame::page() const + 9 1 com.apple.WebCore 0x956c2b09 WebCore::FrameLoader::load(WebCore::FrameLoadRequest const&, bool, bool, WebCore::Event*, WebCore::HTMLFormElement*, WTF::HashMap<WebCore::String, WebCore::String, WebCore::StringHash, WTF::HashTraits<WebCore::String>, WTF::HashTraits> const&) + 745 2 com.apple.WebCore 0x956ca5a3 WebCore::FrameLoader::urlSelected(WebCore::FrameLoadRequest const&, WebCore::Event*, bool, bool) + 311 3 com.apple.WebCore 0x956ca205 WebCore::FrameLoader::urlSelected(WebCore::ResourceRequest const&, WebCore::String const&, WebCore::Event*, bool, bool) + 337 4 com.apple.WebCore 0x956c9d7f WebCore::FrameLoader::changeLocation(WebCore::KURL const&, WebCore::String const&, bool, bool) + 651 5 com.apple.WebCore 0x956c9ae2 WebCore::FrameLoader::changeLocation(WebCore::String const&, WebCore::String const&, bool, bool) + 96 6 com.apple.WebCore 0x956c976e WebCore::FrameLoader::redirectionTimerFired(WebCore::Timer<WebCore::FrameLoader>*) + 90 7 com.apple.WebCore 0x95a5c3fc WebCore::Timer<WebCore::FrameLoader>::fired() + 72 8 com.apple.WebCore 0x9574b5a4 WebCore::TimerBase::fireTimers(double, WTF::Vector<WebCore::TimerBase*, (unsigned long)0> const&) + 74 9 com.apple.WebCore 0x9574b3de WebCore::TimerBase::sharedTimerFired() + 144 10 com.apple.WebCore 0x9574b335 WebCore::timerFired(__CFRunLoopTimer*, void*) + 63 11 com.apple.CoreFoundation 0x9082d756 CFRunLoopRunSpecific + 3341 12 com.apple.CoreFoundation 0x9082ca42 CFRunLoopRunInMode + 61 13 com.apple.HIToolbox 0x92df6878 RunCurrentEventLoopInMode + 285 14 com.apple.HIToolbox 0x92df5f82 ReceiveNextEventCommon + 385 15 com.apple.HIToolbox 0x92df5dd9 BlockUntilNextEventMatchingListInMode + 81 16 com.apple.AppKit 0x9327cf45 _DPSNextEvent + 572 17 com.apple.AppKit 0x9327cb37 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 137 18 com.apple.Safari 0x0000761f 0x1000 + 26143 19 com.apple.AppKit 0x932768c4 -[NSApplication run] + 512 20 com.apple.AppKit 0x9326a820 NSApplicationMain + 573 21 com.apple.Safari 0x000a960e 0x1000 + 689678 22 com.apple.Safari 0x000a9535 0x1000 + 689461
Nevermind, I see the crash on 3.1 now. But still don't see it on current ToT. I'm about to land a test case with a fix for a different bug that covers this one, so I think we can close it.