Steps to reproduce: 1. Open the attached test case. 2. Click "OK" in alerts as they pop up. 3. Experience a crash This is 100% reproducible for me with a local debug build of r30190. Thread 0 Crashed: 0 com.apple.JavaScriptCore 0x005da8de WTF::Vector<KJS::LocalStorageEntry, 32ul>::shrink(unsigned long) + 130 (Vector.h:635) 1 com.apple.JavaScriptCore 0x006045d0 KJS::JSGlobalObject::popActivation() + 96 (JSGlobalObject.cpp:543) 2 com.apple.JavaScriptCore 0x005962c5 KJS::FunctionExecState::~FunctionExecState() + 137 (ExecState.cpp:213) 3 com.apple.JavaScriptCore 0x005962e7 KJS::FunctionExecState::~FunctionExecState() + 17 (ExecState.cpp:213) 4 com.apple.JavaScriptCore 0x0059b40c KJS::FunctionImp::callAsFunction(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 214 (function.cpp:83) 5 com.apple.JavaScriptCore 0x005a0ef4 KJS::JSObject::call(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 222 (object.cpp:96) 6 com.apple.WebCore 0x01db1866 WebCore::JSCustomSQLStatementCallback::handleEvent(WebCore::SQLTransaction*, WebCore::SQLResultSet*, bool&) + 668 (JSCustomSQLStatementCallback.cpp:87) 7 com.apple.WebCore 0x01f9beeb WebCore::SQLStatement::performCallback(WebCore::SQLTransaction*) + 321 (SQLStatement.cpp:169) 8 com.apple.WebCore 0x01f9e40e WebCore::SQLTransaction::deliverStatementCallback() + 124 (SQLTransaction.cpp:342) 9 com.apple.WebCore 0x01f9d49d WebCore::SQLTransaction::performPendingCallback() + 481 (SQLTransaction.cpp:159) 10 com.apple.WebCore 0x01c2a0b1 WebCore::Database::deliverPendingCallback(void*) + 23 (Database.cpp:525) 11 com.apple.WebCore 0x020a34df -[WebCoreFunctionWrapper invoke] + 23 (Threading.mm:53)
Created attachment 19106 [details] test case
Confirmed also with Webkit r30153 inside Safari 3.1 and also in a "stock" Safari 3.1
*** This bug has been marked as a duplicate of 17329 ***
I can't get a crash in a non-debug build r30208 if I click through everything right away. However, if I wait for the second alert box to appear and then click, I get a crash in KJS::Window::findJSEventListener().
The example wasn't working for me because of the changes to disable local storage in clients that don't implement the proper delegate methods. Mark sent me a patch that removes this restriction, and I was able to reproduce the bug. It crashes for the same reason as bug 17329, JSGlobalObject::reset() is called while there is still a single element on the activation stack, causing the next call to JSGlobalObject::popActivation() to segfault. However, bug 17329 was traced by Geoff down to javascript: links, whereas none of those appear in this example. Therefore, I think that calling this a duplicate of bug 17329 is premature. I will trace the calls to JSGlobalObject::reset() and see why it is being called in the middle of script execution.
Reopening per the above comment.
Created attachment 19124 [details] Stack trace Here's a stack trace of the call to JSGlobalObject::reset() that causes the problem. My logging tells me that the problem is happening in the iframe, not the main window, so judging by the trace it is probably calling JSGlobalObject::reset() because the iframe is being cleared. Indeed, when I change the code to not clear the iframe, it works fine. I will try to make a reduction that does not involve local storage at all.
Created attachment 19126 [details] Reduction Here is a simple reduction that doesn't involve local storage at all. It just runs an infinite loop that performs dummy function calls in the iframe. When the script gets interrupted for being too slow, click on the JS alert box and then continue. It should crash.
The crash is fixed in r30235, but script execution while a page is being reloaded is still a bit of an issue (the loop in my example keeps running until a function lookup fails).
Cool! Closing as fixed.
Do we need a new bug for the script execution issue? What the correct behavior would be?
(In reply to comment #11) > Do we need a new bug for the script execution issue? What the correct behavior > would be? The question is whether script execution should cease after changing the src of a document while a script is running, but that might be tied up in the general issue of interruptibility of JavaScript.