<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><div style="font-family: Helvetica; font-size: 12px;">I see. Thanks for straightening that out.</div><div style="font-family: Helvetica; font-size: 12px;"><br class=""></div><div style="font-family: Helvetica; font-size: 12px;">Perhaps you can advise on a good strategy to move forward. My ability to debug these crashes is limited. This is the one that led me to attempt disabling DFG:</div><div style="font-family: Helvetica; font-size: 12px;"><br class=""></div><div style="font-family: Helvetica; font-size: 12px;"><span class="" style="font-family: 'Courier New'; font-size: 13px;">#0 0x00007ffff0da6012 in JSC::Register::jsValue (this=0x7fff9cbd2ff8) at ../../Source/JavaScriptCore/interpreter/Register.h:118</span></div><div style="font-family: Helvetica; font-size: 12px;"><div id="bloop_sign_1411104670406849792" class="bloop_sign" style="font-size: 13px;"><font face="Courier New" class="">#1 0x00007ffff0f77d79 in JSC::DFG::prepareOSREntry (exec=0x7fff9cbd3248, codeBlock=Reading in symbols for ../../Source/JavaScriptCore/bytecode/CodeBlock.cpp...done.</font></div><div id="bloop_sign_1411104670406849792" class="bloop_sign" style="font-size: 13px;"><font face="Courier New" class="">0xd87c00, bytecodeIndex=0x0) at ../../Source/JavaScriptCore/dfg/DFGOSREntry.cpp:169</font></div><div id="bloop_sign_1411104670406849792" class="bloop_sign" style="font-size: 13px;"><font face="Courier New" class="">#2 0x00007ffff10adb1e in JSC::operationOptimize (exec=0x7fff9cbd3248, bytecodeIndex=0x0) at ../../Source/JavaScriptCore/jit/JITOperations.cpp:1157</font></div><div id="bloop_sign_1411104670406849792" class="bloop_sign" style="font-size: 13px;"><font face="Courier New" class="">#3 0x00007fffa87ad871 in ?? ()</font></div><div id="bloop_sign_1411104670406849792" class="bloop_sign" style="font-size: 13px;"><font face="Courier New" class="">#4 0x00007fffa868c920 in ?? ()</font></div><div id="bloop_sign_1411104670406849792" class="bloop_sign" style="font-size: 13px;"><font face="Courier New" class="">#5 0x000000000058d890 in ?? ()</font></div><div id="bloop_sign_1411104670406849792" class="bloop_sign" style="font-size: 13px;"><font face="Courier New" class="">#6 0x000000000219ad30 in ?? ()</font></div><div id="bloop_sign_1411104670406849792" class="bloop_sign" style="font-size: 13px;"><font face="Courier New" class="">#7 0x00000000014c56a0 in ?? ()</font></div><div id="bloop_sign_1411104670406849792" class="bloop_sign" style="font-size: 13px;"><font face="Courier New" class="">#8 0x0000000000441e80 in ?? ()</font></div><div id="bloop_sign_1411104670406849792" class="bloop_sign" style="font-size: 13px;"><font face="Courier New" class="">#9 0x00007ffff21419e0 in thread_context_stack () from libglib-2.0.so.0</font></div><div id="bloop_sign_1411104670406849792" class="bloop_sign" style="font-size: 13px;"><font face="Courier New" class="">#10 0x00007fffffffd1a0 in ?? ()</font></div><div id="bloop_sign_1411104670406849792" class="bloop_sign" style="font-size: 13px;"><font face="Courier New" class="">#11 0x00007ffff1099f50 in JSC::JITCode::execute (this=0x7fff7acc3730, vm=0x7fff7acc3730, protoCallFrame=Reading in symbols for ../../Source/JavaScriptCore/interpreter/Interpreter.cpp...done.</font></div></div><div style="font-family: Helvetica; font-size: 12px;"><br class=""></div><div style="font-family: Helvetica; font-size: 12px;">Numerous commits went into this area subsequent to the 2.4 branch, but it’s not easy to even try them because so much code has changed. What do you think of the idea of cherry-picking an entire JSC from safari-600.x info WebKitGTK 2.4.4? Benjamin suggested going to safari-600.17, but I wonder about API changes if I move that far forward.</div><div style="font-family: Helvetica; font-size: 12px;"><br class=""></div><div style="font-family: Helvetica; font-size: 12px;">Thanks,</div><div style="font-family: Helvetica; font-size: 12px;">Gary</div></div> <div id="bloop_sign_1412750521219682816" class="bloop_sign"></div> <br><p style="color:#000;">On October 7, 2014 at 11:14:51 PM, Carlos Garcia Campos (<a href="mailto:carlosgc@webkit.org">carlosgc@webkit.org</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>El mar, 07-10-2014 a las 19:26 -0700, Gary Kratkin escribió:<br>> Hello, I’m using WebKitGtk 2.4.4. It branched from trunk at r163300 on<br>> Feb. 03, 2014. That may not have been a great moment for<br>> JavaScriptCore. The jsCStack branch had recently been merged,<br><br>That's not accurate due to the confusing svn. r163300 is the revision<br>where the "branch" was made (the copy), but the branch point was<br>r163026, right before the jsCStack merge in r163027. See<br>http://trac.webkit.org/changeset/163300/releases/WebKitGTK/webkit-2.4<br>and click on the "trunk" link.<br><br>> and 2.4.4 has numerous JSC crashes, especially in DFG.<br>> Disabling DFG is a reasonable short-term solution for my use case,<br>> but it leaves one crash I’m having trouble debugging. The release<br>> build crashes here:<br>> <br>> <br>> #0 0x00007f1ffd385710 in JSC::JSCell::toBoolean(JSC::ExecState*) const<br>> () from libjavascriptcoregtk-1.0.so.0<br>> #1 0x00007f1ffd3ac7f0 in ?? () from libjavascriptcoregtk-1.0.so.0<br>> #2 0x00007f1ffd3b6de3 in ?? () from libjavascriptcoregtk-1.0.so.0<br>> #3 0x00007f1ff7a5d018 in ?? ()<br>> #4 0x00007f1ff7a5d000 in ?? ()<br>> #5 0x00007f1fb40af970 in ?? ()<br>> #6 0x00007f1f7dec6a28 in ?? ()<br>> #7 0x00007f1fac4b0ff8 in ?? ()<br>> #8 0x00007fffe0e09000 in ?? ()<br>> #9 0x00007fffe0e08da0 in ?? ()<br>> #10 0x00007f1ffd36bada in JSC::JITCode::execute(JSC::VM*,<br>> JSC::ProtoCallFrame*, JSC::Register*) () from<br>> libjavascriptcoregtk-1.0.so.0<br>> Backtrace stopped: previous frame inner to this frame (corrupt<br>> stack?) <br>> <br>> <br>> The debug build asserts:<br>> <br>> <br>> #0 0x00007f434f2e692f in WTFCrash ()<br>> at ../../Source/WTF/wtf/Assertions.cpp:333<br>> #1 0x00007f434eefe7ba in JSC::validateCell<JSC::Structure*><br>> (cell=0x3569a30)<br>> at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:53<br>> #2 0x00007f434eefe39d in<br>> JSC::WriteBarrierBase<JSC::Structure>::operator-><br>> (this=0x7f42fd3bba90)<br>> at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:123<br>> #3 0x00007f434ef1d4fc in JSC::JSCell::isString (this=0x7f42fd3bba90)<br>> at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:124<br>> #4 0x00007f434ef290e3 in JSC::JSCell::toBoolean (this=0x7f42fd3bba90,<br>> exec=0x7f42fd3bb878)<br>> at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:188<br>> #5 0x00007f434ef290b5 in JSC::JSValue::toBoolean<br>> (this=0x7fff20ff7410, exec=0x7f42fd3bb878)<br>> at ../../Source/JavaScriptCore/runtime/JSString.h:521<br>> #6 0x00007f434f085a84 in JSC::operationConvertJSValueToBoolean<br>> (exec=0x7f42fd3bb878, encodedOp=0x7f42fd3bba90)<br>> at ../../Source/JavaScriptCore/jit/JITOperations.cpp:861<br>> #7 0x00007f43069fc99c in ?? ()<br>> #8 0x00007f43069218e0 in ?? ()<br>> #9 0x000000000274c130 in ?? ()<br>> #10 0x000000000301f740 in ?? ()<br>> #11 0x00000000031e5eb0 in ?? ()<br>> #12 0x0000000003295eb8 in ?? ()<br>> #13 0x00007f434a8eae08 in WebCore::JSDOMWindowBase::supportsProfiling<br>> (object=0x7f43069218e0)<br>> at ../../Source/WebCore/bindings/js/JSDOMWindowBase.cpp:121<br>> #14 0x00007fff20ff74c0 in ?? ()<br>> #15 0x00007f434f06f74c in JSC::JITCode::execute<br>> (this=0xf0458b4832eb0000, vm=0xb8077500f07d,<br>> protoCallFrame=0x8348f04589480000, topOfStack=0xdb6e8c7894860c0)<br>> at ../../Source/JavaScriptCore/jit/JITCode.cpp:48<br>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)<br>> <br>> <br>> My question isn’t how to debug this, though any insights would be<br>> welcome. Instead I’m hoping to to roll JSC forward or backward to a<br>> more stable revision somewhere near 02/2014 (in order to reduce<br>> problems merging into WebKitGtk). It seems best to tie it to a<br>> contemporaneous Safari release, perhaps from the safari-600.1 branch.<br>> I’m wondering if that branch is considered always stable, and<br>> therefore safe to pull from at an arbitrary revision. Alternatively,<br>> is there a way to discover the revision for a given Safari release?<br>> <br>> <br>> Thanks for any help,<br>> Gary<br>> <br>> <br>> _______________________________________________<br>> webkit-dev mailing list<br>> webkit-dev@lists.webkit.org<br>> https://lists.webkit.org/mailman/listinfo/webkit-dev<br><br><br>_______________________________________________<br>webkit-dev mailing list<br>webkit-dev@lists.webkit.org<br>https://lists.webkit.org/mailman/listinfo/webkit-dev<br></div></div></span></blockquote></body></html>