Bug 115796 – ASSERTION FAILED: callFrame->lexicalGlobalObject() == globalObject : JSValue JSC::JSScope::resolveGlobal(CallFrame *, const Identifier &, JSGlobalObject *, ResolveOperation *)

• Component: JavaScriptCore
• Status: NEW

[Simon Pena]

Created attachment 201061 [details]
Test case demonstrating the issue. Run in a web server.

We are using the GTK+ 64-bit port, with r149667.

We have a scenario where we are repeatedly calling a JavaScript
method in an iframe which interacts with other JavaScript in the
parent document.

We are using setTimeout / setInterval to get this periodic calls, and
with JIT enabled, after the method is called enough times, the
following assertion will fail:

ASSERT_UNUSED(globalObject, callFrame->lexicalGlobalObject() == globalObject);

which is in JSC::JSScope::resolveGlobal at Source/JavaScriptCore/runtime/JSScope.cpp:619

#0  0x00007f22cc502186 in JSC::JSScope::resolveGlobal (callFrame=0x7f216e3ed058, identifier=, globalObject=0x7f217005f470, resolveOperation=0x8470e0) at ../../Source/JavaScriptCore/runtime/JSScope.cpp:619
#1  0x00007f22cc2e7625 in JSC::DFG::operationResolveGlobal (exec=0x7f216e3ed058, resolveOperation=0x8470e0, globalObject=0x7f217005f470, propertyName=0xa9ebb8) at ../../Source/JavaScriptCore/dfg/DFGOperations.cpp:1263
#2  0x00007f227f38459c in ?? ()
#3  0x00007f216e3ed058 in ?? ()
#4  0x0000000000000008 in ?? ()
#5  0x00007fffc9ff3140 in ?? ()
#6  0x00007f22cc3b40d1 in JSC::JSStack::installTrapsAfterFrame (this=0x0, frame=0x0) at ../../Source/JavaScriptCore/interpreter/JSStackInlines.h:213
#7  0x00007f22cc3b2e00 in JSC::JITCode::execute (this=0x7f217010f690, stack=0x8db600, callFrame=0x7f216e3ed058, vm=0x9625b0) at ../../Source/JavaScriptCore/jit/JITCode.h:135
#8  0x00007f22cc3b0704 in JSC::Interpreter::executeCall (this=0x8db5f0, callFrame=0x7f217005f078, function=0x7f21700ae3b0, callType=JSC::CallTypeJS, callData=..., thisValue=..., args=...) at ../../Source/JavaScriptCore/interpreter/Interpreter.cpp:1052

With JIT disabled, our scenario works fine. It is worth noting that
with a simpler version of our changeColor method the crash won't
appear (I am not familiar with JSC and JIT, but it might be that the
method would be so simple that it doesn't need to be compiled?)

Also, when the same functionality is done without involving iframes,
the crash doesn't happen.

I am attaching a test case which triggers the bug with GtkLauncher and
MiniBrowser, the full stack trace for both, and a core file resulting
from running GtkLauncher.

In order to run the test, maybe a web server will be needed to avoid
the different origin security warnings.

[Simon Pena]

Created attachment 201063 [details]
Core dump after running the test case with GtkLauncher

[Simon Pena]

Created attachment 201065 [details]
Full stack trace of the crash with GtkLauncher

[Simon Pena]

Created attachment 201066 [details]
Full stack trace of the crash with MiniBrowser

[Simon Pena]

Oliver, I'm CCing you because you have worked with this, in case you can quickly detect if something is wrong, or suggest some lines of investigation.

[Oliver Hunt]

Hmmm, could you try disabling the DFG, or inlining?

My supposition is that we end up inlining a call to a function from another page, in which case i suspect that this assertion is wrong.  Will look at it when i get into the office.

Alternatively it's possible that there's something horrifying happening when inlining (specifically we end up trying to resolve off the wrong global)

[Simon Pena]

(In reply to comment #5)
> Hmmm, could you try disabling the DFG, or inlining?

Sure, I will check that and report back

[Simon Pena]

An additional finding: in the test case attached, we are calling Math.round. Replacing that call with (x + 0.5) << 1) >> 1 no longer triggers the bug.

[Simon Pena]

(In reply to comment #5)
> Hmmm, could you try disabling the DFG, or inlining?
> 
> My supposition is that we end up inlining a call to a function from another page, in which case i suspect that this assertion is wrong.  Will look at it when i get into the office.
> 
> Alternatively it's possible that there's something horrifying happening when inlining (specifically we end up trying to resolve off the wrong global)

Sorry, it took me a while to come back: I initially tried to disable DFG in build time, and found bug #90183, so I stopped there. Today I came back to this and learned about the Options interface and the way to pass env variables to JSC.

So, if I disable DFG with JSC_useDFGJIT=false, it won't crash. If I disable inlining with JSC_maximumInliningDepth=1, it won't crash either.