[webkit-dev] Determining stable JavaScriptCore revision

[Benjamin Poulain]

safari-600.1.17 is in a good state, try getting JSC from there. Getting 
your release branch from the Safari branch seems like a good plan, it 
has been stabilizing for a while.

Benjamin

On 10/7/14, 7:26 PM, Gary Kratkin wrote:
> 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
> <https://surfcrew.lighthouseapp.com/projects/120856/tickets/0> 0x00007f1ffd385710
> in JSC::JSCell::toBoolean(JSC::ExecState*) const () from
> libjavascriptcoregtk-1.0.so.0
> #1
> <https://surfcrew.lighthouseapp.com/projects/120856/tickets/1> 0x00007f1ffd3ac7f0
> in ?? () from libjavascriptcoregtk-1.0.so.0
> #2
> <https://surfcrew.lighthouseapp.com/projects/120856/tickets/2> 0x00007f1ffd3b6de3
> in ?? () from libjavascriptcoregtk-1.0.so.0
> #3
> <https://surfcrew.lighthouseapp.com/projects/120856/tickets/3> 0x00007f1ff7a5d018
> in ?? ()
> #4
> <https://surfcrew.lighthouseapp.com/projects/120856/tickets/4> 0x00007f1ff7a5d000
> in ?? ()
> #5
> <https://surfcrew.lighthouseapp.com/projects/120856/tickets/5> 0x00007f1fb40af970
> in ?? ()
> #6
> <https://surfcrew.lighthouseapp.com/projects/120856/tickets/6> 0x00007f1f7dec6a28
> in ?? ()
> #7
> <https://surfcrew.lighthouseapp.com/projects/120856/tickets/7> 0x00007f1fac4b0ff8
> in ?? ()
> #8
> <https://surfcrew.lighthouseapp.com/projects/120856/tickets/8> 0x00007fffe0e09000
> in ?? ()
> #9
> <https://surfcrew.lighthouseapp.com/projects/120856/tickets/9> 0x00007fffe0e08da0
> in ?? ()
> #10
> <https://surfcrew.lighthouseapp.com/projects/120856/tickets/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
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>