Re: [webkit-dev] Determining stable JavaScriptCore revision

[Gary Kratkin]

I haven’t. The commit list didn’t look relevant, especially since we’re on wk1.

-Gary

On October 8, 2014 at 4:28:57 AM, Alberto Garcia (be...@igalia.com) wrote:

On Tue, Oct 07, 2014 at 11:50:29PM -0700, Gary Kratkin wrote:

> 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.

I noticed an increase of stability in the 2.4.6 release of WebKitGTK+,
did you try that one?

Berto
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Determining stable JavaScriptCore revision

[Alberto Garcia]

On Tue, Oct 07, 2014 at 11:50:29PM -0700, Gary Kratkin wrote:

> 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.

I noticed an increase of stability in the 2.4.6 release of WebKitGTK+,
did you try that one?

Berto
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Determining stable JavaScriptCore revision

[Gary Kratkin]

I see. Thanks for straightening that out.

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:

#0  0x70da6012 in JSC::Register::jsValue (this=0x7fff9cbd2ff8) at 
../../Source/JavaScriptCore/interpreter/Register.h:118
#1  0x70f77d79 in JSC::DFG::prepareOSREntry (exec=0x7fff9cbd3248, 
codeBlock=Reading in symbols for 
../../Source/JavaScriptCore/bytecode/CodeBlock.cpp...done.
0xd87c00, bytecodeIndex=0x0) at 
../../Source/JavaScriptCore/dfg/DFGOSREntry.cpp:169
#2  0x710adb1e in JSC::operationOptimize (exec=0x7fff9cbd3248, 
bytecodeIndex=0x0) at ../../Source/JavaScriptCore/jit/JITOperations.cpp:1157
#3  0x7fffa87ad871 in ?? ()
#4  0x7fffa868c920 in ?? ()
#5  0x0058d890 in ?? ()
#6  0x0219ad30 in ?? ()
#7  0x014c56a0 in ?? ()
#8  0x00441e80 in ?? ()
#9  0x721419e0 in thread_context_stack () from libglib-2.0.so.0
#10 0x7fffd1a0 in ?? ()
#11 0x71099f50 in JSC::JITCode::execute (this=0x7fff7acc3730, 
vm=0x7fff7acc3730, protoCallFrame=Reading in symbols for 
../../Source/JavaScriptCore/interpreter/Interpreter.cpp...done.

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.

Thanks,
Gary

On October 7, 2014 at 11:14:51 PM, Carlos Garcia Campos (carlo...@webkit.org) 
wrote:

El mar, 07-10-2014 a las 19:26 -0700, Gary Kratkin escribió:
> 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,

That's not accurate due to the confusing svn. r163300 is the revision
where the "branch" was made (the copy), but the branch point was
r163026, right before the jsCStack merge in r163027. See
http://trac.webkit.org/changeset/163300/releases/WebKitGTK/webkit-2.4
and click on the "trunk" link.

> 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 0x7f1ffd385710 in JSC::JSCell::toBoolean(JSC::ExecState*) const
> () from libjavascriptcoregtk-1.0.so.0
> #1 0x7f1ffd3ac7f0 in ?? () from libjavascriptcoregtk-1.0.so.0
> #2 0x7f1ffd3b6de3 in ?? () from libjavascriptcoregtk-1.0.so.0
> #3 0x7f1ff7a5d018 in ?? ()
> #4 0x7f1ff7a5d000 in ?? ()
> #5 0x7f1fb40af970 in ?? ()
> #6 0x7f1f7dec6a28 in ?? ()
> #7 0x7f1fac4b0ff8 in ?? ()
> #8 0x7fffe0e09000 in ?? ()
> #9 0x7fffe0e08da0 in ?? ()
> #10 0x7f1ffd36bada 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 0x7f434f2e692f in WTFCrash ()
> at ../../Source/WTF/wtf/Assertions.cpp:333
> #1 0x7f434eefe7ba in JSC::validateCell
> (cell=0x3569a30)
> at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:53
> #2 0x7f434eefe39d in
> JSC::WriteBarrierBase::operator->
> (this=0x7f42fd3bba90)
> at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:123
> #3 0x7f434ef1d4fc in JSC::JSCell::isString (this=0x7f42fd3bba90)
> at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:124
> #4 0x7f434ef290e3 in JSC::JSCell::toBoolean (this=0x7f42fd3bba90,
> exec=0x7f42fd3bb878)
> at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:188
> #5 0x7f434ef290b5 in JSC::JSValue::toBoolean
> (this=0x7fff20ff7410, exec=0x7f42fd3bb878)
> at ../../Source/JavaScriptCore/runtime/JSString.h:521
> #6 0x7f434f085a84 in JSC::operationConvertJSValueToBoolean
> (exec=0x7f42fd3bb878, encodedOp=0x7f42fd3bba90)
> at ../../Source/JavaScriptCore/jit/JITOperations.cpp:861
> #7 0x7f43069fc99c in ?? ()
> #8 0x7f43069218e0 in ?? ()
> #9 0x0274c130 in ?? ()
> #10 0x0301f740 in ?? ()
> #11 0x031e5eb0 in ?? ()
> #12 0x03295eb8 in ?? ()
> #13 0x7f434a8eae08 in WebCore::JSDOMWindowBase::supportsProfiling
> (object=0x7f43069218e0)
> at ../../Source/WebCore/bindings/js/JSDOMWindowBase.cpp:121
> #14 0x7fff20ff74c0 in ?? ()
> #15 0x7f434f06f74c in JSC::JITCode::execute
> (this=0xf0458b4832eb, vm=0xb8077500f07d,
> protoCallFrame=0x8348f0458948, 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

Re: [webkit-dev] Determining stable JavaScriptCore revision

[Carlos Garcia Campos]

El mar, 07-10-2014 a las 19:26 -0700, Gary Kratkin escribió:
> 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,

That's not accurate due to the confusing svn. r163300 is the revision
where the "branch" was made (the copy), but the branch point was
r163026, right before the jsCStack merge in r163027. See
http://trac.webkit.org/changeset/163300/releases/WebKitGTK/webkit-2.4
and click on the "trunk" link.

>  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 0x7f1ffd385710 in JSC::JSCell::toBoolean(JSC::ExecState*) const
> () from libjavascriptcoregtk-1.0.so.0
> #1 0x7f1ffd3ac7f0 in ?? () from libjavascriptcoregtk-1.0.so.0
> #2 0x7f1ffd3b6de3 in ?? () from libjavascriptcoregtk-1.0.so.0
> #3 0x7f1ff7a5d018 in ?? ()
> #4 0x7f1ff7a5d000 in ?? ()
> #5 0x7f1fb40af970 in ?? ()
> #6 0x7f1f7dec6a28 in ?? ()
> #7 0x7f1fac4b0ff8 in ?? ()
> #8 0x7fffe0e09000 in ?? ()
> #9 0x7fffe0e08da0 in ?? ()
> #10 0x7f1ffd36bada 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  0x7f434f2e692f in WTFCrash ()
> at ../../Source/WTF/wtf/Assertions.cpp:333
> #1  0x7f434eefe7ba in JSC::validateCell
> (cell=0x3569a30)
> at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:53
> #2  0x7f434eefe39d in
> JSC::WriteBarrierBase::operator->
> (this=0x7f42fd3bba90)
> at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:123
> #3  0x7f434ef1d4fc in JSC::JSCell::isString (this=0x7f42fd3bba90)
> at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:124
> #4  0x7f434ef290e3 in JSC::JSCell::toBoolean (this=0x7f42fd3bba90,
> exec=0x7f42fd3bb878)
> at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:188
> #5  0x7f434ef290b5 in JSC::JSValue::toBoolean
> (this=0x7fff20ff7410, exec=0x7f42fd3bb878)
> at ../../Source/JavaScriptCore/runtime/JSString.h:521
> #6  0x7f434f085a84 in JSC::operationConvertJSValueToBoolean
> (exec=0x7f42fd3bb878, encodedOp=0x7f42fd3bba90)
> at ../../Source/JavaScriptCore/jit/JITOperations.cpp:861
> #7  0x7f43069fc99c in ?? ()
> #8  0x7f43069218e0 in ?? ()
> #9  0x0274c130 in ?? ()
> #10 0x0301f740 in ?? ()
> #11 0x031e5eb0 in ?? ()
> #12 0x03295eb8 in ?? ()
> #13 0x7f434a8eae08 in WebCore::JSDOMWindowBase::supportsProfiling
> (object=0x7f43069218e0)
> at ../../Source/WebCore/bindings/js/JSDOMWindowBase.cpp:121
> #14 0x7fff20ff74c0 in ?? ()
> #15 0x7f434f06f74c in JSC::JITCode::execute
> (this=0xf0458b4832eb, vm=0xb8077500f07d,
> protoCallFrame=0x8348f0458948, 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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [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
 
0x7f1ffd385710
in JSC::JSCell::toBoolean(JSC::ExecState*) const () from
libjavascriptcoregtk-1.0.so.0
#1
 
0x7f1ffd3ac7f0
in ?? () from libjavascriptcoregtk-1.0.so.0
#2
 
0x7f1ffd3b6de3
in ?? () from libjavascriptcoregtk-1.0.so.0
#3
 
0x7f1ff7a5d018
in ?? ()
#4
 
0x7f1ff7a5d000
in ?? ()
#5
 
0x7f1fb40af970
in ?? ()
#6
 
0x7f1f7dec6a28
in ?? ()
#7
 
0x7f1fac4b0ff8
in ?? ()
#8
 
0x7fffe0e09000
in ?? ()
#9
 
0x7fffe0e08da0
in ?? ()
#10
 
0x7f1ffd36bada
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  0x7f434f2e692f in WTFCrash () at
../../Source/WTF/wtf/Assertions.cpp:333
#1  0x7f434eefe7ba in JSC::validateCell
(cell=0x3569a30) at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:53
#2  0x7f434eefe39d in
JSC::WriteBarrierBase::operator-> (this=0x7f42fd3bba90)
at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:123
#3  0x7f434ef1d4fc in JSC::JSCell::isString (this=0x7f42fd3bba90) at
../../Source/JavaScriptCore/runtime/JSCellInlines.h:124
#4  0x7f434ef290e3 in JSC::JSCell::toBoolean (this=0x7f42fd3bba90,
exec=0x7f42fd3bb878) at
../../Source/JavaScriptCore/runtime/JSCellInlines.h:188
#5  0x7f434ef290b5 in JSC::JSValue::toBoolean (this=0x7fff20ff7410,
exec=0x7f42fd3bb878) at ../../Source/JavaScriptCore/runtime/JSString.h:521
#6  0x7f434f085a84 in JSC::operationConvertJSValueToBoolean
(exec=0x7f42fd3bb878, encodedOp=0x7f42fd3bba90) at
../../Source/JavaScriptCore/jit/JITOperations.cpp:861
#7  0x7f43069fc99c in ?? ()
#8  0x7f43069218e0 in ?? ()
#9  0x0274c130 in ?? ()
#10 0x0301f740 in ?? ()
#11 0x031e5eb0 in ?? ()
#12 0x03295eb8 in ?? ()
#13 0x7f434a8eae08 in WebCore::JSDOMWindowBase::supportsProfiling
(object=0x7f43069218e0) at
../../Source/WebCore/bindings/js/JSDOMWindowBase.cpp:121
#14 0x7fff20ff74c0 in ?? ()
#15 0x7f434f06f74c in JSC::JITCode::execute
(this=0xf0458b4832eb, vm=0xb8077500f07d,
protoCallFrame=0x8348f0458948, 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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[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 0x7f1ffd385710 in JSC::JSCell::toBoolean(JSC::ExecState*) const () from 
libjavascriptcoregtk-1.0.so.0
#1 0x7f1ffd3ac7f0 in ?? () from libjavascriptcoregtk-1.0.so.0
#2 0x7f1ffd3b6de3 in ?? () from libjavascriptcoregtk-1.0.so.0
#3 0x7f1ff7a5d018 in ?? ()
#4 0x7f1ff7a5d000 in ?? ()
#5 0x7f1fb40af970 in ?? ()
#6 0x7f1f7dec6a28 in ?? ()
#7 0x7f1fac4b0ff8 in ?? ()
#8 0x7fffe0e09000 in ?? ()
#9 0x7fffe0e08da0 in ?? ()
#10 0x7f1ffd36bada 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  0x7f434f2e692f in WTFCrash () at ../../Source/WTF/wtf/Assertions.cpp:333
#1  0x7f434eefe7ba in JSC::validateCell (cell=0x3569a30) 
at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:53
#2  0x7f434eefe39d in JSC::WriteBarrierBase::operator-> 
(this=0x7f42fd3bba90) at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:123
#3  0x7f434ef1d4fc in JSC::JSCell::isString (this=0x7f42fd3bba90) at 
../../Source/JavaScriptCore/runtime/JSCellInlines.h:124
#4  0x7f434ef290e3 in JSC::JSCell::toBoolean (this=0x7f42fd3bba90, 
exec=0x7f42fd3bb878) at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:188
#5  0x7f434ef290b5 in JSC::JSValue::toBoolean (this=0x7fff20ff7410, 
exec=0x7f42fd3bb878) at ../../Source/JavaScriptCore/runtime/JSString.h:521
#6  0x7f434f085a84 in JSC::operationConvertJSValueToBoolean 
(exec=0x7f42fd3bb878, encodedOp=0x7f42fd3bba90) at 
../../Source/JavaScriptCore/jit/JITOperations.cpp:861
#7  0x7f43069fc99c in ?? ()
#8  0x7f43069218e0 in ?? ()
#9  0x0274c130 in ?? ()
#10 0x0301f740 in ?? ()
#11 0x031e5eb0 in ?? ()
#12 0x03295eb8 in ?? ()
#13 0x7f434a8eae08 in WebCore::JSDOMWindowBase::supportsProfiling 
(object=0x7f43069218e0) at 
../../Source/WebCore/bindings/js/JSDOMWindowBase.cpp:121
#14 0x7fff20ff74c0 in ?? ()
#15 0x7f434f06f74c in JSC::JITCode::execute (this=0xf0458b4832eb, 
vm=0xb8077500f07d, protoCallFrame=0x8348f0458948, 
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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev