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.
Created attachment 201063 [details] Core dump after running the test case with GtkLauncher
Created attachment 201065 [details] Full stack trace of the crash with GtkLauncher
Created attachment 201066 [details] Full stack trace of the crash with MiniBrowser
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.
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)
(In reply to comment #5) > Hmmm, could you try disabling the DFG, or inlining? Sure, I will check that and report back
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.
(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.