Bug 119108 - ASSERT(m_vm->apiLock().currentThreadIsHoldingLock()); fails for Safari on current ToT
Summary: ASSERT(m_vm->apiLock().currentThreadIsHoldingLock()); fails for Safari on cur...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Anders Carlsson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-25 14:53 PDT by Mark Lam
Modified: 2013-07-25 17:12 PDT (History)
6 users (show)

See Also:


Attachments
Patch (5.28 KB, patch)
2013-07-25 17:10 PDT, Anders Carlsson
mhahnenberg: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Lam 2013-07-25 14:53:52 PDT
Here's the back trace:

(gdb) bt
#0  WTFCrash () at /Volumes/Data/ws6/OpenSource/Source/WTF/wtf/Assertions.cpp:339
#1  0x000000010732e094 in JSC::Heap::protect (this=0x7f827a04a418, k={u = {asInt64 = 4627690608, ptr = 0x113d4f470, asBits = {payload = 332723312, tag = 1}}}) at /Volumes/Data/ws6/OpenSource/Source/JavaScriptCore/heap/Heap.cpp:337
#2  0x00000001073bf333 in JSC::gcProtect (val=0x113d4f470) at Protect.h:32
#3  0x00000001073be9b9 in JSGlobalContextRetain (ctx=0x113d4f4e0) at /Volumes/Data/ws6/OpenSource/Source/JavaScriptCore/API/JSContextRef.cpp:158
#4  0x00000001109d8822 in WBSJSController::setContext (this=0x7f827b860690, context=0x113d4f4e0) at /Volumes/Data/ws6/Internal/SafariShared/WBSJSController.mm:107
#5  0x00000001109d8c50 in WBSJSController::scriptObjectReady (this=0x7f827b860690, ctx=0x113d4f4e0) at /Volumes/Data/ws6/Internal/SafariShared/WBSJSController.mm:64
…

The rest of the stack trace shows this initiated from Reader.  I saw this assertion failure crash by launching a debug build of ToT (r153339) with the Safari set to load "http://www.zazzle.com/vintage_zebra_blue_mojo_pillow-189636972500458458" on launch.

Per our conversation, it looks like the assertion is failing because of the recent added code to check for "vm.exclusiveThread".  gdb confirms that this code was active in this case.  Here are the gdb details:

(gdb) frame 3      
#3  0x00000001073be9b9 in JSGlobalContextRetain (ctx=0x113d4f4e0) at /Volumes/Data/ws6/OpenSource/Source/JavaScriptCore/API/JSContextRef.cpp:158
158	    gcProtect(exec->dynamicGlobalObject());
(gdb) list
153	{
154	    ExecState* exec = toJS(ctx);
155	    APIEntryShim entryShim(exec);
156	
157	    VM& vm = exec->vm();
158	    gcProtect(exec->dynamicGlobalObject());
159	    vm.ref();
160	    return ctx;
161	}
162	
(gdb) p vm.exclusiveThread
$1 = 1
 
Based on the APIEntryShim code, this means that it does not acquire the VM lock on allocation of the shim.
Comment 1 Sergio Correia (qrwteyrutiyoup) 2013-07-25 16:23:59 PDT
Not sure it's related, but I get a similar ASSERT [vm()->apiLock().currentThreadIsHoldingLock()] on an EFL build, right after starting MiniBrowser - trying to load google.com. The assert it's hitting is in Heap::collect() [Source/JavaScriptCore/heap/Heap.cpp(714)].
Comment 2 Mark Hahnenberg 2013-07-25 17:02:32 PDT
Change that triggered this: http://trac.webkit.org/changeset/153331
Comment 3 Anders Carlsson 2013-07-25 17:10:09 PDT
Created attachment 207496 [details]
Patch
Comment 4 Mark Hahnenberg 2013-07-25 17:11:21 PDT
Comment on attachment 207496 [details]
Patch

r=me
Comment 5 Anders Carlsson 2013-07-25 17:12:09 PDT
Committed r153357: <http://trac.webkit.org/changeset/153357>