[webkit-dev] Determining stable JavaScriptCore revision

[Gary Kratkin]

Hello, I’m using WebKitGtk 2.4.4. It branched from trunk at r163300 on Feb. 03, 2014. That may not have been a great moment for JavaScriptCore. The jsCStack branch had recently been merged, and 2.4.4 has numerous JSC crashes, especially in DFG. Disabling DFG is a reasonable short-term solution for my use case, but it leaves one crash I’m having trouble debugging. The release build crashes here:

#0 0x00007f1ffd385710 in JSC::JSCell::toBoolean(JSC::ExecState*) const () from libjavascriptcoregtk-1.0.so.0
#1 0x00007f1ffd3ac7f0 in ?? () from libjavascriptcoregtk-1.0.so.0
#2 0x00007f1ffd3b6de3 in ?? () from libjavascriptcoregtk-1.0.so.0
#3 0x00007f1ff7a5d018 in ?? ()
#4 0x00007f1ff7a5d000 in ?? ()
#5 0x00007f1fb40af970 in ?? ()
#6 0x00007f1f7dec6a28 in ?? ()
#7 0x00007f1fac4b0ff8 in ?? ()
#8 0x00007fffe0e09000 in ?? ()
#9 0x00007fffe0e08da0 in ?? ()
#10 0x00007f1ffd36bada in JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*, JSC::Register*) () from libjavascriptcoregtk-1.0.so.0
Backtrace stopped: previous frame inner to this frame (corrupt stack?) 

The debug build asserts:

#0  0x00007f434f2e692f in WTFCrash () at ../../Source/WTF/wtf/Assertions.cpp:333
#1  0x00007f434eefe7ba in JSC::validateCell<JSC::Structure*> (cell=0x3569a30) at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:53
#2  0x00007f434eefe39d in JSC::WriteBarrierBase<JSC::Structure>::operator-> (this=0x7f42fd3bba90) at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:123
#3  0x00007f434ef1d4fc in JSC::JSCell::isString (this=0x7f42fd3bba90) at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:124
#4  0x00007f434ef290e3 in JSC::JSCell::toBoolean (this=0x7f42fd3bba90, exec=0x7f42fd3bb878) at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:188
#5  0x00007f434ef290b5 in JSC::JSValue::toBoolean (this=0x7fff20ff7410, exec=0x7f42fd3bb878) at ../../Source/JavaScriptCore/runtime/JSString.h:521
#6  0x00007f434f085a84 in JSC::operationConvertJSValueToBoolean (exec=0x7f42fd3bb878, encodedOp=0x7f42fd3bba90) at ../../Source/JavaScriptCore/jit/JITOperations.cpp:861
#7  0x00007f43069fc99c in ?? ()
#8  0x00007f43069218e0 in ?? ()
#9  0x000000000274c130 in ?? ()
#10 0x000000000301f740 in ?? ()
#11 0x00000000031e5eb0 in ?? ()
#12 0x0000000003295eb8 in ?? ()
#13 0x00007f434a8eae08 in WebCore::JSDOMWindowBase::supportsProfiling (object=0x7f43069218e0) at ../../Source/WebCore/bindings/js/JSDOMWindowBase.cpp:121
#14 0x00007fff20ff74c0 in ?? ()
#15 0x00007f434f06f74c in JSC::JITCode::execute (this=0xf0458b4832eb0000, vm=0xb8077500f07d, protoCallFrame=0x8348f04589480000, topOfStack=0xdb6e8c7894860c0) at ../../Source/JavaScriptCore/jit/JITCode.cpp:48
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

My question isn’t how to debug this, though any insights would be welcome. Instead I’m hoping to to roll JSC forward or backward to a more stable revision somewhere near 02/2014  (in order to reduce problems merging into WebKitGtk). It seems best to tie it to a contemporaneous Safari release, perhaps from the safari-600.1 branch. I’m wondering if that branch is considered always stable, and therefore safe to pull from at an arbitrary revision. Alternatively, is there a way to discover the revision for a given Safari release?

Thanks for any help,
Gary

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20141007/7228112a/attachment.html>