GNOME Bugzilla – Bug 708996
SIGSEGV at startup
Last modified: 2014-03-14 17:05:35 UTC
Hi. I'm having a reproducible crash here on OpenBSD when I start seahorse. (gdb) run Starting program: /usr/local/bin/seahorse [New process 18244] ** Message: init gpgme version 1.3.1 Program received signal SIGSEGV, Segmentation fault. 0x00001acf9d03a596 in gtk_application_add_window (application=0xffffffffa2c35180, window=0x1acfa2cd64f0) at gtkapplication.c:829 829 g_return_if_fail (GTK_IS_APPLICATION (application)); (gdb) bt
+ Trace 232550
I'm investigating, but just in case someone already knows what is going on... Thank you.
Ok I'm kind of lost in vala-land... maybe this could help someone understand the issue: 0x000010bfcc43a97a in seahorse_catalog_constructor (type=18424678778368, n_construct_properties=4, construct_properties=0x10c1d46f2400) at catalog.c:1298 obj = (GObject *) 0x10c1d46f64d0 parent_class = (GObjectClass *) 0x10c1e65d0000 self = (SeahorseCatalog *) 0x10c1d46f64d0 _tmp0_ = (const gchar *) 0x10c1cdedb140 "key-manager" _tmp1_ = (GtkBuilder *) 0x10c1d73ea840 _tmp2_ = 0x10c1d473eef0 <g_direct_hash> _tmp3_ = 0x10c1d473ef00 <g_direct_equal> _tmp4_ = (GHashTable *) 0x10c1d73ea8c0 _tmp5_ = (GtkUIManager *) 0x10c1d53aa5c0 _tmp6_ = (GtkUIManager *) 0x10c1d53aa5c0 _tmp7_ = (GtkUIManager *) 0x10c1d53aa5c0 _tmp8_ = (GtkUIManager *) 0x10c1d53aa5c0 key = (gchar *) 0x10c1daaa8b80 "/apps/seahorse/windows/key-manager/" _tmp9_ = (const gchar *) 0x10c1cdedb140 "key-manager" _tmp10_ = (gchar *) 0x10c1daaa8b80 "/apps/seahorse/windows/key-manager/" _tmp11_ = (const gchar *) 0x10c1daaa8b80 "/apps/seahorse/windows/key-manager/" _tmp12_ = (GSettings *) 0x10c1d53aa610 width = -1 _tmp13_ = (GSettings *) 0x10c1d53aa610 _tmp14_ = -1 height = -1 _tmp15_ = (GSettings *) 0x10c1d53aa610 _tmp16_ = -1 _tmp17_ = 0 _tmp18_ = -1 _tmp20_ = 0 _tmp33_ = (GtkUIManager *) 0x10c1d53aa5c0 _tmp34_ = (GtkAccelGroup *) 0x10c1d1c1ef60 actions = (GtkActionGroup *) 0x10c1d1be7340 _tmp35_ = (GtkActionGroup *) 0x10c1d1be7340 _tmp36_ = (GtkActionGroup *) 0x10c1d1be7340 _tmp37_ = (GtkActionGroup *) 0x10c1d1be7340 action = (GtkAction *) 0x10c1d5835e80 _tmp38_ = (GtkActionGroup *) 0x10c1d1be7340 _tmp39_ = (GtkAction *) 0x10c1d5835e80 _tmp40_ = (GtkAction *) 0x10c1d5835e80 _tmp41_ = (GtkAction *) 0x10c1d5835e80 _tmp42_ = 1 _tmp43_ = (GtkActionGroup *) 0x10c1d1be7340 _tmp44_ = (GtkAction *) 0x10c1d5835cd0 _tmp45_ = (GtkAction *) 0x10c1d5835cd0 _tmp46_ = (GtkActionGroup *) 0x10c1d1be7340 _tmp47_ = (GtkAction *) 0x10c1d5835d60 _tmp48_ = (GtkAction *) 0x10c1d5835d60 _tmp49_ = (GtkActionGroup *) 0x10c1d1be7340 _tmp50_ = (GtkAction *) 0x10c1d5835c40 _tmp51_ = (GtkAction *) 0x10c1d5835c40 _tmp52_ = (GtkActionGroup *) 0x10c1d1be7340 _tmp53_ = (GtkAction *) 0x10c1d5835b20 _tmp54_ = (GtkAction *) 0x10c1d5835b20 _tmp55_ = (GtkUIManager *) 0x10c1d53aa5c0 _tmp56_ = (GtkActionGroup *) 0x10c1d1be7340 _tmp57_ = (GtkApplication *) 0xffffffffd1dbf180 _inner_error_ = (GError *) 0x0
Could you attach the catalog.c with which you're seeing this failure?
Created attachment 258638 [details] catalog.c from version 3.10.1 Hi Stef. Here's it is -- this is the stock one from the seahorse 3.10.1 tarball. Thanks.
Hi Stef. So I guess nothing rings a bell... :-/
Hey Stef. Any input on this or do you need more info? Thank you.
I would suggest running under valgrind to track why @application seems to be invalid memory. But no valgrind on openbsd, I guess. Worth setting a breakpoint in seahorse_application_finalize() to see if something is unreferencing it erroneously, causing it to be freed.
(In reply to comment #6) > I would suggest running under valgrind to track why @application seems to be > invalid memory. But no valgrind on openbsd, I guess. That is unfortunate but true... no valgrind here. > Worth setting a breakpoint in seahorse_application_finalize() to see if > something is unreferencing it erroneously, causing it to be freed. Just tried and that is not it it seems. It looks like the crash happens earlier than that.
Created attachment 265750 [details] [review] Guessing at a fix... So is seahorse_application_get() being called before seahorse_application_constructed()? Does this patch help?
(In reply to comment #8) > Created an attachment (id=265750) [details] [review] > Guessing at a fix... > > So is seahorse_application_get() being called before > seahorse_application_constructed()? > > Does this patch help? Nope, I am still getting the segfault. I'll post more info tomorrow morning...
Ok I have a full backtrace with glib2, gtk+3 and seahorse built with debug symbols available here: https://www.bsdfrog.org/tmp/seahorse.txt I also tried building seahorse with an older vala (0.20.1 instead of 0.22.1) but that didn't help... I tried playing with your patch Stef as well as trying other stuffs to prevent some unref but not luck so far...
Hi Stef. I am still at loss here :-/ It seems it fails because of this in gtk_application_add_window() (gtk+): g_return_if_fail (GTK_IS_APPLICATION (application)); It worked perfectly before the move to vala.
Hi, I reproduced the bug and it seems that the pointer the_application failed between seahorse_application_get and gtk_application_add_window: - the_application in seahorse_application_get: 0x9fb8c672180 - application in gtk_application_add_window: 0xffffffff8c672180 If I manually set application to 0x9fb8c672180 in gdb, the application started. Maybe my gdb command could help you to understand: % gdb seahorse Starting program: /usr/local/bin/seahorse Breakpoint 1 at 0x9f980744528: file seahorse-application.c, line 282. Breakpoint 3 at 0x9fb90ce9700: file gtkapplication.c, line 825. Pending breakpoint "gtk_application_add_window" resolved [New process 28477] ** Message: init gpgme version 1.3.1 Breakpoint 1, seahorse_application_get () at seahorse-application.c:282 282 g_return_val_if_fail (the_application != NULL, NULL); (gdb) p the_application $1 = (SeahorseApplication *) 0x9fb8c672180 (gdb) n 283 return GTK_APPLICATION (the_application); (gdb) p the_application $2 = (SeahorseApplication *) 0x9fb8c672180 (gdb) s gtk_application_get_type () at gtkapplication.c:175 175 G_DEFINE_TYPE_WITH_PRIVATE (GtkApplication, gtk_application, G_TYPE_APPLICATION) (gdb) p the_application $3 = (SeahorseApplication *) 0x9fb8c672180 (gdb) bt
+ Trace 233144
Thanks you, Remi.
Hi, do you have time to have a look, or do you need more information? To simplify the problem (beause my last post was long): Breakpoint 1, seahorse_application_get () at seahorse-application.c:282 282 g_return_val_if_fail (the_application != NULL, NULL); (gdb) n 283 return GTK_APPLICATION (the_application); (gdb) p the_application $1 = (SeahorseApplication *) 0x18dfc3cdc180 (gdb) p GTK_APPLICATION(the_application) $2 = (struct _GtkApplication *) 0xffffffffc3cdc180 You can see that the GTK_APPLICATION(the_application) does not return the correct value. Don't hesitate if you need more information, Thanks, Remi.
(In reply to comment #13) > Hi, > > do you have time to have a look, or do you need more information? > > To simplify the problem (beause my last post was long): > > Breakpoint 1, seahorse_application_get () at seahorse-application.c:282 > 282 g_return_val_if_fail (the_application != NULL, NULL); > (gdb) n > 283 return GTK_APPLICATION (the_application); > (gdb) p the_application > $1 = (SeahorseApplication *) 0x18dfc3cdc180 > (gdb) p GTK_APPLICATION(the_application) > $2 = (struct _GtkApplication *) 0xffffffffc3cdc180 > > > You can see that the GTK_APPLICATION(the_application) does not return the > correct value. Even though I don't have a working debugger. I'm seeing the same thing. This is very strange. Even changing the cast to (GtkApplication *) still causes truncation of the value in the pointer. Something somewhere is pretty broken. If you look at the C code generated from vala it's not doing anything fancy. Editing that code manually you can see that the value returned from seahorse_application_get() is different from the value returned from seahorse_application_get().
Created attachment 269776 [details] [review] common: Include correct headers for vala calling C code These caused crashes due to pointers being casted to int. Also force compiler errors when functions have no declaration during vala code compilation. Due to the way vala code is generated, this fix may require you to: $ rm common/*.c $ make clean all
Could you test the above fix and see if it fixes the problem? The patch should work on either gnome-3-10 or master.
(In reply to comment #16) > Could you test the above fix and see if it fixes the problem? The patch should > work on either gnome-3-10 or master. Woohoo! That works perfectly, this is awesome :-) Thanks a million for finding this out...
Attachment 269776 [details] pushed as e46d5eb - common: Include correct headers for vala calling C code
*** Bug 726331 has been marked as a duplicate of this bug. ***