Bug 17338 - A crash in popActivation when playing evil games with database support
Summary: A crash in popActivation when playing evil games with database support
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P1 Normal
Assignee: Nobody
URL:
Keywords: HasReduction
Depends on:
Blocks:
 
Reported: 2008-02-13 00:48 PST by Alexey Proskuryakov
Modified: 2008-02-15 11:08 PST (History)
1 user (show)

See Also:


Attachments
test case (1.65 KB, application/zip)
2008-02-13 00:48 PST, Alexey Proskuryakov
no flags Details
Stack trace (15.34 KB, text/plain)
2008-02-14 13:01 PST, Cameron Zwarich (cpst)
no flags Details
Reduction (732 bytes, application/octet-stream)
2008-02-14 14:21 PST, Cameron Zwarich (cpst)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 2008-02-13 00:48:07 PST
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)
Comment 1 Alexey Proskuryakov 2008-02-13 00:48:29 PST
Created attachment 19106 [details]
test case
Comment 2 Robert Blaut 2008-02-13 02:43:05 PST
Confirmed also with Webkit r30153 inside Safari 3.1 and also in a "stock" Safari 3.1
Comment 3 Adam Roben (:aroben) 2008-02-13 08:28:26 PST

*** This bug has been marked as a duplicate of 17329 ***
Comment 4 Cameron Zwarich (cpst) 2008-02-13 14:17:20 PST
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().
Comment 5 Cameron Zwarich (cpst) 2008-02-13 23:06:01 PST
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.
Comment 6 Alexey Proskuryakov 2008-02-14 05:20:56 PST
Reopening per the above comment.
Comment 7 Cameron Zwarich (cpst) 2008-02-14 13:01:38 PST
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.
Comment 8 Cameron Zwarich (cpst) 2008-02-14 14:21:51 PST
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.
Comment 9 Cameron Zwarich (cpst) 2008-02-14 16:35:22 PST
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).
Comment 10 Alexey Proskuryakov 2008-02-15 00:38:49 PST
Cool! Closing as fixed.
Comment 11 Alexey Proskuryakov 2008-02-15 00:39:39 PST
Do we need a new bug for the script execution issue? What the correct behavior would be?
Comment 12 Cameron Zwarich (cpst) 2008-02-15 11:08:21 PST
(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.