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

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

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

Just a side note: The official Pi folks have been working on optimizations specific to the Pi / armv6 architecture: http://blog.barisione.org/2014-09/rpi-browser/ Among these are "JavaScript JIT fixes for ARMv6". Perhaps that version works better (also in terms of performace and stability),

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

2015-10-13 21:34 GMT+02:00 Nick Hudson : > 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 >> r120x7fffb8c8 2147465416 >> >> Breakpoint 1, 0x46213ff4 in g_dpgettext2 ()

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

On 05/31/15 18:07, Stephan wrote: Hi folks, I am currently testing some applications on the RPI 2. Some work pretty well, others not yet. As for webkit-gtk based browsers, I am experiencing crashes from time to time. One problem that occurs often seems to be related to g_dpgettext2 () from

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

Thanks all for your input. Nick was right that the stack pointer needs to be aligned on a 8-byte boundary. I was totally unaware that the calling convention requires this. The g_dpgettext2() function runs successfully a couple of times when epiphany launches. It is then called with an

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

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 r120x7fffb8c8 2147465416 Breakpoint 1, 0x46213ff4 in g_dpgettext2 () from /usr/pkg/lib/libglib-2.0.so.0 (gdb) i r $r12 r120x7fffb870

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

On Thu 08 Oct 2015 at 17:59:22 +, Stephan wrote: > IMHO it would be valid to pass the value of sp as the first argument > (mov r0, sp). However, the way how r0 is computed looks quite > obfuscated to me: > >0x4621402c : mov r3, sp=> ? >0x46214030

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

Folks, more on this topic: This -8<-- (gdb) x/5i 0x45fd3efc 0x45fd3efc: add r12, pc, #1048576 ; 0x10 0x45fd3f00: add r12, r12, #4096 ; 0x1000 0x45fd3f04: ldr pc, [r12, #1652]! ; 0x674 0x45fd3f08: add r12, pc, #1048576 ;

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

Default stack size limits on evbarm are too low for webkit-gtk. Bump it up with ulimit -s and the g_dpgettext2 problem should go away. On Sun, 31 May 2015, Stephan wrote: Hi folks, I am currently testing some applications on the RPI 2. Some work pretty well, others not yet. As for

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

I saw the same issue a while back, don't remember exactly which version of glib2 it was. I LD_PRELOAD'd a version of g_dpgettext2 that always returned NULL and it made the crashes go away. g_dpgettext2 uses alloca internally, so I increased stack size and the crashes went away again.

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

Hi folks, I am currently testing some applications on the RPI 2. Some work pretty well, others not yet. As for webkit-gtk based browsers, I am experiencing crashes from time to time. One problem that occurs often seems to be related to g_dpgettext2 () from glib2. The top of the stack looks like