Usually very low addresses are due to some struct pointer being NULL, so that accessing a member will result in (almost) null dereference. So maybe pike sets something to NULL when cleaning up and GTK still tries to access that later. I have not looked at anything here, just a wild guess.
arne
On 03/03/16 11:27, Chris Angelico wrote:
On Thu, Mar 3, 2016 at 8:53 PM, Arne Goedeke el@laramies.com wrote:
Try compiling --without-machine-code and --with-valgrind, this will get rid of most of the false positives.
Thanks - that gets rid of most of the noise.
This seems to be what's happening:
$ sudo apt-get install libglib2.0-0-dbg libgtk2.0-0-dbg $ make CONFIGUREARGS='--with-valgrind --with-debug --without-machine-code' $ bin/pike --valgrind=--track-origins=yes ../signalcrash
Baboom! /home/rosuav/signalcrash.pike:8: /home/rosuav/signalcrash()->__lambda_65649_1_line_8() -:1: Pike.Backend(0)->`()(3600.0) ==25116== Invalid read of size 8 ==25116== at 0xC01A7F0: signal_emit_unlocked_R (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2) ==25116== by 0xC023D2B: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2) ==25116== by 0xC02405E: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2) ==25116== by 0xC00D473: g_object_dispatch_properties_changed (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2) ==25116== by 0xC00F900: g_object_notify (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2) ==25116== by 0xA803371: gtk_widget_send_focus_change (gtkwidget.c:11445) ==25116== by 0xA8035F2: do_focus_change (gtkwindow.c:5304) ==25116== by 0xA80DA48: _gtk_window_set_has_toplevel_focus (gtkwindow.c:8474) ==25116== by 0xA80DC5E: gtk_window_focus_out_event (gtkwindow.c:5336) ==25116== by 0xA6DF9BB: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:86) ==25116== by 0xC008F44: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2) ==25116== by 0xC01B53D: signal_emit_unlocked_R (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2) ==25116== Address 0x59 is not stack'd, malloc'd or (recently) free'd
An address of 0x59 looks like an error of some sort. It seems to be fairly consistently using that value, which corresponds to 89 decimal or 'Y' in ASCII.
Unfortunately, valgrind is only able to find addresses inside GTK, so I guess the next step would be to somehow trace this number 0x59?
ChrisA