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 <stephan...@googlemail.com>: > 2015-10-13 21:34 GMT+02:00 Nick Hudson <sk...@netbsd.org>: >> 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