Re: Debugging Epiphany/Midori (webkit-gtk based) on earmv6hf (RPI 2)

[Stephan <stephanwib%googlemail.com@localhost>]

After looking at the code, I´m pretty certain it´s the JavaScriptCore
JIT compiler* who generates some assembly on a heap segment which then
calls library functions with a misaligned stack pointer. The version
of webkit-gtk which I built from a recent pkgsrc release is 2.4.8. The
best thing to do first is trying the current version (2.10) of
webkit-gtk I guess.


* https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/assembler/ARMAssembler.h


2015-10-14 7:56 GMT+02:00 Stephan <stephanwib%googlemail.com@localhost>:
> 2015-10-13 21:34 GMT+02:00 Nick Hudson <skrll%netbsd.org@localhost>:
>> On 10/13/15 17:58, Stephan wrote:
>>
>>>
>>> Breakpoint 1, 0x46213ff4 in g_dpgettext2 () from
>>> /usr/pkg/lib/libglib-2.0.so.0
>>> (gdb) i r $r12
>>> r12            0x7fffb8c8       2147465416
>>>
>>> Breakpoint 1, 0x46213ff4 in g_dpgettext2 () from
>>> /usr/pkg/lib/libglib-2.0.so.0
>>> (gdb) i r $r12
>>> r12            0x7fffb870       2147465328
>>>
>>> Contrary, sp is broken in the non-working case:
>>>
>>> (gdb) i r $r12
>>> r12            0x7fffa414       2147460116
>>>
>>> Unfortunately, the call trace is incomplete in that case:
>>
>> r13 is sp.
>
> Sure. When I use gdb, I set a breakpoint on <function>. In practise,
> the breakpoint hits after the stack frame was set up by that function,
> e.g. when sp was already lowered to allocate space for local variables
> (or the stack pointer was potentially aligned like gcc on x86 does).
> On gcc/ARM, ip (r12) gets a copy of sp on the first instruction of the
> function prologue. That´s why I monitored r12 (another solution could
> be to break on *function+0, but I haven´t tested that).
>
>>
>> debug symbols (compile flag -g) will help a lot here.
>>
>
> Uff... ATM it looks like Webkit is at fault. It took 2 days to compile
> on the RPI2 so it could take a long time to get the symbols ready.
> Also the last thing I´ve seen yesterday was that the frame where gdb
> stopped being able to follow the stack was special. Basically
> speaking, I think the condition that makes this crash happen is when a
> new tab/page is supposed to open from a JavaScript event - so it´s
> likely that the JS interpreter is on the call trace. The code to the
> said frame where gdb stops was executable memory (rwx) residing in an
> [anon] region. I´m not sure whether symbols can help in this case nor
> what else can... ;)
>
>>
>> Nick