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

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

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 appropriately aligned stack pointer:

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:

#35 0x40c42178 in
WebCore::EventTarget::dispatchEvent(WTF::PassRefPtr<WebCore::Event>,
int&) () from /usr/pkg/lib/libwebkitgtk-1.0.so.0
#36 0x4147fd84 in
WebCore::jsNodePrototypeFunctionDispatchEvent(JSC::ExecState*) () from
/usr/pkg/lib/libwebkitgtk-1.0.so.0
#37 0x43fc81a4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The only thing I can say just now is that sp is already misaligned in
frame 36 when it comes out of this obfuscated frame 37. I set a
separate breakpoint as it seems not too easy to get the value of sp
for each frame on a full call trace:


Breakpoint 1, 0x4147fc94 in
WebCore::jsNodePrototypeFunctionDispatchEvent(JSC::ExecState*) () from
/usr/pkg/lib/libwebkitgtk-1.0.so.0
(gdb) bt
#0  0x4147fc94 in
WebCore::jsNodePrototypeFunctionDispatchEvent(JSC::ExecState*) () from
/usr/pkg/lib/libwebkitgtk-1.0.so.0
#1  0x50add124 in ?? ()

(gdb) i r $r12
r12            0x7fffb88c 2147465356


This is not too easy :)

2015-10-13 8:17 GMT+00:00 Nick Hudson <skrll%netbsd.org@localhost>:
> 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 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 0x45f5587c in g_object_new_valist () from
>> /usr/pkg/lib/libgobject-2.0.so.0
>> #11 0x45f55a24 in g_object_new () from /usr/pkg/lib/libgobject-2.0.so.0
>> #12 0x00043ff0 in ephy_window_new_with_chrome ()
>> #13 0x0003ac94 in ephy_shell_new_tab_full ()
>> #14 0x0003f81c in ?? ()
>> #15 0x40a090e8 in webkit_marshal_OBJECT__OBJECT () from
>> /usr/pkg/lib/libwebkitgtk-1.0.so.0
>> #16 0x45f4e070 in g_closure_invoke () from
>> /usr/pkg/lib/libgobject-2.0.so.0
>> #17 0x45f6154c in signal_emit_unlocked_R () from
>> /usr/pkg/lib/libgobject-2.0.so.0
>> #18 0x45f69278 in g_signal_emit_valist () from
>> /usr/pkg/lib/libgobject-2.0.so.0
>> #19 0x45f69cac in g_signal_emit_by_name () from
>> /usr/pkg/lib/libgobject-2.0.so.0
>> #20 0x409d9074 in
>> WebKit::FrameLoaderClient::dispatchCreatePage(WebCore::NavigationAction
>> const&) () from /usr/pkg/lib/libwebkitgtk-1.0.so.0
>> ...
>
>
> I'm pretty sure the problem is that somewhere in the call stack the
> sp isn't 8-byte aligned and the alloca in g_dpgettext2 falls over this
>
> Move up the frames doing up; info frame (or similar)
>
> Nick