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 ; 0x10
0x45fd3f0c: add r12, r12, #4096 ; 0x1000
---
is not garbage. It's kind of a link table (plt) inside of glib2. It
makes the first 2 calls in g_dpgettext2() go to strlen() and the third
go to memcpy(). memcpy() saves the r0 and lr regisers at the very
beginning and pops them into r0 and pc at a later time in order to
return to the caller. However somewhere in the function, the stack
data seems to become corrupted and a junk value is loaded into pc,
leading to the crash. Either its value was overwritten or sp is
pointing to the wrong place.
(gdb) x/50i 0x45e80f98
0x45e80f98 : push {r0, lr}=> SAVE REGISTERS
0x45e80f9c : subs r2, r2, #4
0x45e80fa0 : blt 0x45e81028
0x45e80fa4 : ands r12, r0, #3
0x45e80fa8 : bne 0x45e81050
0x45e80fac : ands r12, r1, #3
0x45e80fb0 : bne 0x45e81080
0x45e80fb4 : subs r2, r2, #8
0x45e80fb8 : blt 0x45e81008
0x45e80fbc : subs r2, r2, #20
0x45e80fc0 : blt 0x45e80ff4
0x45e80fc4 : push {r4} ; (str r4, [sp, #-4]!)
0x45e80fc8 : ldm r1!, {r3, r4, r12, lr}
0x45e80fcc : stmia r0!, {r3, r4, r12, lr}
0x45e80fd0 : ldm r1!, {r3, r4, r12, lr}
0x45e80fd4 : stmia r0!, {r3, r4, r12, lr}
0x45e80fd8 : subs r2, r2, #32
0x45e80fdc : bge 0x45e80fc8
0x45e80fe0 : cmn r2, #16
0x45e80fe4 : ldmge r1!, {r3, r4, r12, lr}
0x45e80fe8 : stmiage r0!, {r3, r4, r12, lr}
0x45e80fec : subge r2, r2, #16
0x45e80ff0 : pop {r4} ; (ldr r4, [sp], #4)
0x45e80ff4 : adds r2, r2, #20
0x45e80ff8 : ldmge r1!, {r3, r12, lr}
0x45e80ffc : stmiage r0!, {r3, r12, lr}
0x45e81000 : subsge r2, r2, #12
0x45e81004 : bge 0x45e80ff8
0x45e81008 : adds r2, r2, #8
0x45e8100c : blt 0x45e81028
0x45e81010 : subs r2, r2, #4
0x45e81014 : ldrlt r3, [r1], #4
0x45e81018 : strlt r3, [r0], #4
0x45e8101c : ldmge r1!, {r3, r12}
0x45e81020 : stmiage r0!, {r3, r12}
0x45e81024 : subge r2, r2, #4
0x45e81028 : adds r2, r2, #4
0x45e8102c : popeq {r0, pc}
0x45e81030 : cmp r2, #2
0x45e81034 : ldrb r3, [r1], #1
0x45e81038 : strb r3, [r0], #1
0x45e8103c : ldrbge r3, [r1], #1
0x45e81040 : strbge r3, [r0], #1
0x45e81044 : ldrbgt r3, [r1], #1
0x45e81048 : strbgt r3, [r0], #1
=> 0x45e8104c : pop {r0, pc} ==> CRASH: PC
gets corrupted value
0x45e81050 : rsb r12, r12, #4
Further investigation is to come ;)
2015-05-31 19:05 GMT+00:00 Jared McNeill :
> 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.
>
> https://git.gnome.org/browse/glib/tree/glib/ggettext.c#n271
>
>
> On Sun, 31 May 2015, Stephan wrote:
>
>>
>> That does not help unfortunately - just tested again with ulimit -s
>> unlimited. I dont think we are hitting the stack boundary
>> because sp is still inside the stack region outlined by pmap. Have you
>> seen the very same issue as I do?
>>
>> Am 31.05.2015 19:48 schrieb "Jared McNeill" :
>> 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 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 this:
>>
>> (gdb) bt
>> #0 0x636f7452 in ?? ()
>> #1 0x45ff3fa8 in g_dpgettext2 () from
>> /usr/pkg/lib/libglib-2.0.so.0
>> #2 0x42ad6030 in gtk_stock_lookup () from
>> /usr/pkg/lib/libgtk-x11-2.0.so.0
>> #3 0x42987b98 in gtk_action_set_stock_id () from
>> /usr/pkg/lib/libgtk-x11-2.0.so.0
>> #4 0x45f55cfc in g_object_set_valist () from
>> /usr/pkg/lib/libgobject-2.0.so.0
>> #5 0x45f5642c in g_object_set () from
>> /usr/pkg/lib/libgobject-2.0.so.0
>> #6 0x4298a27c in gtk_action_group_add_actions_full () from
>> /usr/pkg/lib/libgtk-x11-2.0.so.0
>> #7 0x4298a388 in gtk_action_group_add_actions () from
>> /usr/pkg/lib/libgtk-x11-2.0.so.0
>> #8 0x0004238c in ?? ()
>> #9 0x45f5322c in g_object_new_internal () from
>> /usr/pkg/lib/libgobject-2.0.so.0
>> #10 0x
