| Summary: | opening account preferences window crashes when compiled with ./configure --disable-dbus | ||
|---|---|---|---|
| Product: | Claws Mail (GTK 2) | Reporter: | Martin Väth <claws-mail> |
| Component: | UI/Actions | Assignee: | users |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | other | ||
| Hardware: | PC | ||
| OS: | Linux | ||
|
Description
Martin Väth
2018-01-15 08:08:47 UTC
Can you attach the full backtrace? Even though the crash happens within GLib, it would be interesting to see where the trace leaves Claws Mail code. I cannot reproduce that with newer versions of those libraries which you listed. Which suggests to me that it is not our bug. (In reply to comment #2) > I cannot reproduce that with newer versions of those libraries which you > listed. I had also tried after an experimental upgrade to glib-2.52.3 but still had the same problem. > Which suggests to me that it is not our bug. What looks suspicious to me for --disable-dbus is the warning: (claws-mail:32739): GLib-GObject-WARNING **: cannot register existing type 'DBusGProxy This lets me conjecture that perhaps some #ifdef for dbus-related stuff is missing somewhere in the code. (In reply to comment #1) > Can you attach the full backtrace? Despite compiling with C{,XX}FLAGS=''-O0 -g -ggdb3 -no-pie -fno-PIE' I did not get a sane backtrace. (I have several protection mechanisms like gcc-7.2.0 w/ pie+ssp and ASLR in the kernel which might be the culprit for this...) #0 0x00007ffff7153d64 in g_main_context_prepare () from /usr/lib64/libglib-2.0.so.0 #1 0x00007fff00000000 in ?? () #2 0x00000000008ee240 in ?? () #3 0x00007fffffff8dd4 in ?? () #4 0x00007fffffff8d74 in ?? () #5 0xffffffff00000018 in ?? () #6 0x177c939869fa1300 in ?? () #7 0x000000000090f6a0 in ?? () #8 0x000000000090f6a0 in ?? () #9 0x000000000090f6a0 in ?? () #10 0x0000000000d626a0 in ?? () #11 0x0000000000000001 in ?? () #12 0x0000000000000005 in ?? () #13 0x0000000000cf1550 in ?? () #14 0x00007ffff715488e in ?? () from /usr/lib64/libglib-2.0.so.0 #15 0x0000000000e95e00 in ?? () #16 0x0000000100000027 in ?? () #17 0x00007fffffff8f10 in ?? () #18 0x177c939869fa1300 in ?? () #19 0x000000000090f6a0 in ?? () #20 0x0000000000e95e00 in ?? () #21 0x000000000090f6a0 in ?? () #22 0x0000000000e95e0c in ?? () #23 0x0000000000cf1550 in ?? () #24 0x00007fffffffa120 in ?? () #25 0x00007ffff71ebc00 in ?? () from /usr/lib64/libgobject-2.0.so.0 #26 0x00007ffff7155f12 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #27 0x0000000000e95e00 in ?? () #28 0x0000000000b987d0 in ?? () #29 0x00007fffffff8f10 in ?? () #30 0x0000000000b987d0 in ?? () #31 0x00007fffffff8f10 in ?? () #32 0x0000000000000000 in ?? () DBusGProxy is from building with network-manager support. Try this and see if it still crashes: Quit claws-mail. open ~/.claws-mail/clawsrc set use_networkmanager=0 (In reply to comment #4) > DBusGProxy is from building with network-manager support. I don't have networkmanager installed. The warning occurs also if I build with --disable-networkmanager (In reply to comment #5) > Try this and see if it still crashes: > Quit claws-mail. > open ~/.claws-mail/clawsrc > set use_networkmanager=0 Unfortunately, the crash is still there. But also the warning is still there. As for the backtrace, it would probably be more useful if you installed the package with debug symbols (claws-mail-debug or claws-mail-dbg in most distributions). (In reply to comment #7) > if you installed the package with debug symbols As mentioned, I have compiled with C{,XX}FLAGS="-g -ggdb3 -O0", so debug symbols are there. The problem with the backtrace is probably some pie/ASLR mangling which interferes with gdb. Maybe late this evening I have some time to investigate this issue, but I cannot promise in the moment. > claws-mail-debug or claws-mail-dbg in most distributions I am using gentoo, not a binary distribution. (I also doubt that there is any binary distribution which ships claws-mail without dbus support which is a necessary condition to produce the problem...) I tried it with --disable-dbus and could not reproduce it, so it's not simply that. Anyway the point was that your backtrace was made with stripped binaries and no debug info, so however you do that, a more meaningful backtrace is needed. As far as I know, neither ASLR nor PIC/PIE is a problem when working with gdb. My guess is that you do not have the splitdebug feature enabled in your make.conf. see https://wiki.gentoo.org/wiki/Debugging#Don.27t_strip_symbols for more details. (In reply to comment #10) > As far as I know, neither ASLR nor PIC/PIE is a problem when working with > gdb. This used to be different some years ago until gdb was fixed. I was conjecturing that this fix was perhaps not up-to-date for the new gcc -fPIE implementation. But it seems now that it works indeed fine (see below). > My guess is that you do not have the splitdebug feature enabled I have called ./configure ... && make (no make install) manually as a user and have run it directly from the src-directory. In fact, the symbols are there and debugging works perfectly: After adding an artificial assignment to *NULL for testing purposes, I got a completely sane backtrace with function and variable names. But after the above crash, I still get only the meaningless junk... Of course, glib & friends are not compiled with debugging symbols, but this does not explain why there does not appear at least one function from claws-mail. Maybe this crash occurs in some auxiliary thread, only, which exists only within glib? As a last attempt, I installed glib with debugging symbols.
And indeed, all symbols from the backtrace are _only_ from glib:
#0 0x00007ffff706c916 in g_main_context_prepare (context=0x828f50, priority=0x7fffffff8840) at ../../glib-2.50.3/glib/gmain.c:3494
#1 0x00007ffff706d200 in g_main_context_iterate (context=0x828f50, block=1, dispatch=1, self=0xbcb0c0) at ../../glib-2.50.3/glib/gmain.c:3909
#2 0x00007ffff706d6fa in g_main_loop_run (loop=0x9bb710) at ../../glib-2.50.3/glib/gmain.c:4125
#3 0x00007ffff7886fa7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#4 0x00000000004fb6fc in prefs_account_open (ac_prefs=ac_prefs@entry=0xb44270, dirty=dirty@entry=0x7fffffff897c) at prefs_account.c:3915
#5 0x000000000044e43d in account_open (ac_prefs=0xb44270) at account.c:472
#6 0x00007ffff71579b6 in g_cclosure_marshal_VOID__VOID (closure=0x852f10, return_value=0x0, n_param_values=1, param_values=0x7fffffff9be0, invocation_hint=0x7fffffff9b20, marshal_data=0x0)
at ../../glib-2.50.3/gobject/gmarshal.c:875
#7 0x00007ffff7154968 in g_closure_invoke (closure=0x852f10, return_value=0x0, n_param_values=1, param_values=0x7fffffff9be0, invocation_hint=0x7fffffff9b20) at ../../glib-2.50.3/gobject/gclosure.c:804
#8 0x00007ffff7170fbc in signal_emit_unlocked_R (node=0x87aea0, detail=0, instance=0x899710, emission_return=0x0, instance_and_params=0x7fffffff9be0) at ../../glib-2.50.3/gobject/gsignal.c:3635
#9 0x00007ffff71702c9 in g_signal_emit_valist (instance=0x899710, signal_id=136, detail=0, var_args=0x7fffffff9e98) at ../../glib-2.50.3/gobject/gsignal.c:3391
#10 0x00007ffff717084c in g_signal_emit (instance=0x899710, signal_id=136, detail=0) at ../../glib-2.50.3/gobject/gsignal.c:3447
#11 0x00007ffff77c35af in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#12 0x00007ffff71579b6 in g_cclosure_marshal_VOID__VOID (closure=0x8e5f60, return_value=0x0, n_param_values=1, param_values=0x7fffffffa220, invocation_hint=0x7fffffffa160, marshal_data=0x7ffff78984e0)
at ../../glib-2.50.3/gobject/gmarshal.c:875
#13 0x00007ffff7154fbc in g_type_class_meta_marshal (closure=0x8e5f60, return_value=0x0, n_param_values=1, param_values=0x7fffffffa220, invocation_hint=0x7fffffffa160, marshal_data=0x378)
at ../../glib-2.50.3/gobject/gclosure.c:997
#14 0x00007ffff7154968 in g_closure_invoke (closure=0x8e5f60, return_value=0x0, n_param_values=1, param_values=0x7fffffffa220, invocation_hint=0x7fffffffa160) at ../../glib-2.50.3/gobject/gclosure.c:804
#15 0x00007ffff7170cd2 in signal_emit_unlocked_R (node=0x8e5fc0, detail=0, instance=0x993910, emission_return=0x0, instance_and_params=0x7fffffffa220) at ../../glib-2.50.3/gobject/gsignal.c:3565
#16 0x00007ffff71702c9 in g_signal_emit_valist (instance=0x993910, signal_id=151, detail=0, var_args=0x7fffffffa4d8) at ../../glib-2.50.3/gobject/gsignal.c:3391
#17 0x00007ffff717084c in g_signal_emit (instance=0x993910, signal_id=151, detail=0) at ../../glib-2.50.3/gobject/gsignal.c:3447
#18 0x00007ffff79a8475 in gtk_widget_activate () from /usr/lib64/libgtk-x11-2.0.so.0
#19 0x00007ffff789c6ad in gtk_menu_shell_activate_item () from /usr/lib64/libgtk-x11-2.0.so.0
#20 0x00007ffff789c9f2 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#21 0x00007ffff788971e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#22 0x00007ffff7154fbc in g_type_class_meta_marshal (closure=0x80d3a0, return_value=0x7fffffffa7f0, n_param_values=2, param_values=0x7fffffffa8e0, invocation_hint=0x7fffffffa820, marshal_data=0x160)
at ../../glib-2.50.3/gobject/gclosure.c:997
#23 0x00007ffff7154968 in g_closure_invoke (closure=0x80d3a0, return_value=0x7fffffffa7f0, n_param_values=2, param_values=0x7fffffffa8e0, invocation_hint=0x7fffffffa820)
at ../../glib-2.50.3/gobject/gclosure.c:804
#24 0x00007ffff717113e in signal_emit_unlocked_R (node=0x80d3f0, detail=0, instance=0x984ad0, emission_return=0x7fffffffa9c0, instance_and_params=0x7fffffffa8e0) at ../../glib-2.50.3/gobject/gsignal.c:3673
#25 0x00007ffff717035f in g_signal_emit_valist (instance=0x984ad0, signal_id=42, detail=0, var_args=0x7fffffffaba8) at ../../glib-2.50.3/gobject/gsignal.c:3401
#26 0x00007ffff717084c in g_signal_emit (instance=0x984ad0, signal_id=42, detail=0) at ../../glib-2.50.3/gobject/gsignal.c:3447
#27 0x00007ffff79a988c in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#28 0x00007ffff7887cfc in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0
#29 0x00007ffff788811b in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#30 0x00007ffff7f5ac0f in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#31 0x00007ffff706c26b in g_main_dispatch (context=0x828f50) at ../../glib-2.50.3/glib/gmain.c:3203
#32 0x00007ffff706d0f0 in g_main_context_dispatch (context=0x828f50) at ../../glib-2.50.3/glib/gmain.c:3856
#33 0x00007ffff706d2d4 in g_main_context_iterate (context=0x828f50, block=1, dispatch=1, self=0xbcb0c0) at ../../glib-2.50.3/glib/gmain.c:3929
#34 0x00007ffff706d6fa in g_main_loop_run (loop=0x92ac50) at ../../glib-2.50.3/glib/gmain.c:4125
#35 0x00007ffff7886fa7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#36 0x0000000000449ff1 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1614
By systematic inserting of fprintf(stderr, ...) I finally binsected the problem (claws-mail-3.16.0): 1. The crash finally occurs in the call of gtk_main() in prefs_account.c 2. The warning/error messages (which do not occur with --enable-dbus) are printed in the 5th iteration of the loop prefswindow_build_all_pages(). More precisely, they are printed then in prefswindow_build_page() in the call page->create_widget(page, GTK_WINDOW(prefswindow->window), prefswindow->data); You can print out page->path[1] (a gchar*) to uniquely identify which page is being dealt with at the moment. If you run claws-mail with --debug flag, you can also use debug_print(), which is basically fprintf(stderr, ...) with some trimmings. :) I forgot to add that you can then go inside the create_widget function of that particular page (in prefs_account.c), and continue adding your debug output to further isolate where the crash happens. I found now the offending library call: enchant_broker_list_dicts(broker, list_dict_cb, &list); (in the file src/gtk/gtkaspell.c in function gtkaspell_get_dictionary_list). When I comment it out, there are no warnings/errors and no crash. Note that the above call happens twice when opening the account preferences window: In the first call there is no warning/error printed, but in the second call it is. Maybe for some reason the enchant_broker_list_dicts() function must be called only once? To be more precise: The warnings/errors are printed (in the second call) *before* the callback function list_dict_cb() is executed. what version of enchant are you using? 1.6.1 (Versions 2.1.0 and 2.1.1 are masked in gentoo due to incompatible API changes). It seems to be a pure enchant-1.6.1 bug: No problems with enchant-2.1.1 (with claws-mail-3.16.0; claws-mail-3.15.1 did not compile with enchant-2.1.1). Sorry for the noise. |