I've only seen this crash on the chromium platform. Crashes consistently for me on Linux (Lucid) and occasionally for me on Mac (Snow Leopard). Did not try on Windows. The test fast/frames/iframe-reparenting.html runs fine on its own, but seg faults when testing all fast/frames. I've narrowed the repro case down to making it fail by only running 2 layout tests: new-run-webkit-tests --chromium --use-drt --verbose --no-show-results fast/frames/iframe-reparenting-new-page.html fast/frames/iframe-reparenting.html 2010-10-29 14:31:29,847 dump_render_tree_thread.py:106 DEBUG Stacktrace for /work/WebKit/LayoutTests/fast/frames/iframe-reparenting.html: [8574:8574:1284969651047:ERROR:WebKit/chromium/base/process_util_posix.cc(105)] Received signal 11 StackTrace::StackTrace() [0x86e060] base::(anonymous namespace)::StackDumpSignalHandler() [0x89f0c1] 0x7fac40bb3af0 WebCore::Page::group() [0x468736] WebCore::V8Proxy::didLeaveScriptContext() [0xdc8ab4] WebCore::V8Proxy::callFunction() [0xdc8629] WebCore::ScheduledAction::execute() [0xd994f3] WebCore::ScheduledAction::execute() [0xd9933e] WebCore::DOMTimer::fired() [0x10cc370] WebCore::ThreadTimers::sharedTimerFiredInternal() [0xd0705c] WebCore::ThreadTimers::sharedTimerFired() [0xd06f8f] webkit_glue::WebKitClientImpl::DoTimeout() [0x17ba32e] DispatchToMethod<>() [0x17ba751] base::BaseTimer<>::TimerTask::Run() [0x17ba6a6] MessageLoop::RunTask() [0x87fb5e] MessageLoop::DeferOrRunPendingTask() [0x87fc42] MessageLoop::DoDelayedWork() [0x8803c5] base::MessagePumpForUI::HandleDispatch() [0x8d065b] (anonymous namespace)::WorkSourceDispatch() [0x8cfa53] 0x7fac438898c2 0x7fac4388d748 0x7fac4388d8fc base::MessagePumpForUI::RunOnce() [0x8d03d7] base::MessagePumpForUI::RunWithDispatcher() [0x8d0270] base::MessagePumpForUI::Run() [0x8d0ad2] MessageLoop::RunInternal() [0x87f29e] MessageLoop::RunHandler() [0x87f13c] MessageLoop::Run() [0x87f0cd] webkit_support::RunMessageLoop() [0x584c91] TestShell::waitTestFinished() [0x454fb9] TestShell::runFileTest() [0x44e5b1] runTest() [0x429685] main [0x429ff2] 0x7fac40b9ec4d 0x418c59 breakpoint in V8Proxy::didLeaveScriptContext shows m_frame has a refcount of -1 and its m_page is an invalid pointer.
Upon further testing, I can get this to crash with just fast/frames/iframe-reparenting-new-page.html if using DumpRenderTree directly (passes with new-run-webkit-tests): out/Debug/DumpRenderTree /work/WebKit/LayoutTests/fast/frames/iframe-reparenting-new-page.html Content-Type: text/plain The test verifies that the timer in iframe continues firing after iframe is adopted into a new window and the original window was closed. On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". PASS successfullyParsed is true TEST COMPLETE PASS Loaded iframe in window 1. PASS iframe.contentWindow.counter is 1 PASS Loaded page 2. PASS Page 2 adopted the iframe. PASS Iframe transferred. PASS iframe.contentWindow.counter is 2 PASS window2.location.href is iframe.contentWindow.parent.location.href PASS Page 1 is closed. PASS Received the timer beat from the adopted iframe - exiting. #EOF [14304:14304:1546383445592:ERROR:WebKit/chromium/base/process_util_posix.cc(105)] Received signal 11 StackTrace::StackTrace() [0x86dfec] base::(anonymous namespace)::StackDumpSignalHandler() [0x89f04d] 0x7f1780d51af0 WebCore::Page::group() [0x4686c6] WebCore::V8Proxy::didLeaveScriptContext() [0xdc8a40] WebCore::V8Proxy::callFunction() [0xdc85b5] WebCore::ScheduledAction::execute() [0xd9947f] WebCore::ScheduledAction::execute() [0xd992ca] WebCore::DOMTimer::fired() [0x10cc2fc] WebCore::ThreadTimers::sharedTimerFiredInternal() [0xd06fe8] WebCore::ThreadTimers::sharedTimerFired() [0xd06f1b] webkit_glue::WebKitClientImpl::DoTimeout() [0x17ba2ae] DispatchToMethod<>() [0x17ba6d1] base::BaseTimer<>::TimerTask::Run() [0x17ba626] MessageLoop::RunTask() [0x87faea] MessageLoop::DeferOrRunPendingTask() [0x87fbce] MessageLoop::DoDelayedWork() [0x880351] base::MessagePumpForUI::HandleDispatch() [0x8d05e7] (anonymous namespace)::WorkSourceDispatch() [0x8cf9df] 0x7f1783a278c2 0x7f1783a2b748 0x7f1783a2b8fc base::MessagePumpForUI::RunOnce() [0x8d0363] base::MessagePumpForUI::RunWithDispatcher() [0x8d01fc] base::MessagePumpForUI::Run() [0x8d0a5e] MessageLoop::RunInternal() [0x87f22a] MessageLoop::RunHandler() [0x87f0c8] MessageLoop::Run() [0x87f059] webkit_support::RunMessageLoop() [0x584c1d] TestShell::waitTestFinished() [0x454fb9] TestShell::runFileTest() [0x44e5b1] runTest() [0x429685] main [0x42a0d5] 0x7f1780d3cc4d 0x418c59
This is caused by javascript in fast/frames/resources/iframe-reparenting-new-page.js closing the window that contains the timer in the middle of processing that timer event. I can make the crash disappear by delaying the window close until after the timer event has completed. Should V8 handle this correctly and allow closing a window in the timer callback?
Created attachment 72601 [details] simple test case This simple test case opens a window that contains a timer. When the timer fires, close the window that contains the timer. Crashes with similar stack track. Output included in zip file.
Jenn, thanks a lot for investigation and repro. I don't immediately think it's an issue with v8 itself, rather with the bindings. Still it might be pretty severe. I'll try to investigate it next week, but would appreciate if Adam or Nate would have a look as well, as my experience with frame closing and times is pretty limited. (In reply to comment #3) > Created an attachment (id=72601) [details] > simple test case > > This simple test case opens a window that contains a timer. When the timer fires, close the window that contains the timer. Crashes with similar stack track. Output included in zip file.
The magic iframe feature and the test mentioned here have been removed. Closing.