Bug 3949 - opening account preferences window crashes when compiled with ./configure --disable-dbus
Summary: opening account preferences window crashes when compiled with ./configure --d...
Status: RESOLVED INVALID
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: UI/Actions (show other bugs)
Version: other
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2018-01-15 08:08 CET by Martin Väth
Modified: 2018-01-16 19:29 CET (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Väth 2018-01-15 08:08:47 CET
When attempting to open any account references window
(no matter whether through "Configuration" -> "Preferences for current account" or by pressing "Edit" in the "Edit accounts" window)
there occur the message (output with claw-mail --debug):

prefs_account.c:3793:Opening account preferences window...
prefs_account.c:3795:called inc_lock (lock count 1)
passwordstore.c:180:Getting password 'recv_cert' from block (1/1)
passwordstore.c:185:Block (1/1) not found.
passwordstore.c:180:Getting password 'send_cert' from block (1/1)
passwordstore.c:185:Block (1/1) not found.
gtkaspell.c:1590:Aspell: found dictionary de de
gtkaspell.c:1590:Aspell: found dictionary de_AT de_AT
gtkaspell.c:1590:Aspell: found dictionary en_US en_US
gtkaspell.c:1590:Aspell: found dictionary en en
gtkaspell.c:1590:Aspell: found dictionary en_CA en_CA
gtkaspell.c:1590:Aspell: found dictionary en_GB en_GB
gtkaspell.c:1590:Aspell: found dictionary de_DE de_DE
gtkaspell.c:1590:Aspell: found dictionary de_CH de_CH
gtkaspell.c:1590:Aspell: found dictionary en_AU en_AU

(claws-mail:32739): GLib-GObject-WARNING **: cannot register existing type 'DBusGProxy'

(claws-mail:32739): GLib-GObject-CRITICAL **: g_type_set_qdata: assertion 'node != NULL' failed

(claws-mail:32739): GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed

(claws-mail:32739): GLib-GObject-CRITICAL **: g_type_set_qdata: assertion 'node != NULL' failed

(claws-mail:32739): GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed

(claws-mail:32739): GLib-GObject-CRITICAL **: g_type_set_qdata: assertion 'node != NULL' failed
gtkaspell.c:1590:Aspell: found dictionary de de
gtkaspell.c:1590:Aspell: found dictionary de_AT de_AT
gtkaspell.c:1590:Aspell: found dictionary en_US en_US
gtkaspell.c:1590:Aspell: found dictionary en en
gtkaspell.c:1590:Aspell: found dictionary en_CA en_CA
gtkaspell.c:1590:Aspell: found dictionary en_GB en_GB
gtkaspell.c:1590:Aspell: found dictionary de_DE de_DE
gtkaspell.c:1590:Aspell: found dictionary de_CH de_CH
gtkaspell.c:1590:Aspell: found dictionary en_AU en_AU
passwordstore.c:180:Getting password 'send' from block (1/1)
passwordstore.c:185:Block (1/1) not found.
passwordstore.c:180:Getting password 'recv' from block (1/1)
passwordstore.c:185:Block (1/1) not found.
prefswindow.c:671:0.000000

and then the application segfaults, according to gdb somewhere in glib.

The problem occurs *if and only if* ./configure --disable-dbus is used.
Moreover, the problem did not occur a while ago (when older versions of many libraries like glib and gtk+ etc. had been used: I am a gentoo user, so I have regular library and compiler upgrades).

Currently, the problem is reproducible with claws-mail versions 3.16.0 and 3.15.1 (I didn't try older ones) and the following library versions:
gtk-2.24.31-r1
glib-2.50.3-r1
glibc-2.25-r9
(I can add further if requested.)
Comment 1 Andrej Kacian 2018-01-15 10:20:32 CET
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.
Comment 2 Paul 2018-01-15 10:29:22 CET
I cannot reproduce that with newer versions of those libraries which you listed. Which suggests to me that it is not our bug.
Comment 3 Martin Väth 2018-01-15 12:41:19 CET
(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 ?? ()
Comment 4 Paul 2018-01-15 13:01:21 CET
DBusGProxy is from building with network-manager support.
Comment 5 Paul 2018-01-15 13:03:11 CET
Try this and see if it still crashes:
Quit claws-mail.
open ~/.claws-mail/clawsrc
set use_networkmanager=0
Comment 6 Martin Väth 2018-01-15 13:16:03 CET
(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.
Comment 7 Andrej Kacian 2018-01-15 14:39:35 CET
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).
Comment 8 Martin Väth 2018-01-15 18:34:38 CET
(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...)
Comment 9 Paul 2018-01-15 18:39:31 CET
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.
Comment 10 Andrej Kacian 2018-01-15 19:14:23 CET
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.
Comment 11 Martin Väth 2018-01-15 19:39:21 CET
(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?
Comment 12 Martin Väth 2018-01-16 05:57:49 CET
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
Comment 13 Martin Väth 2018-01-16 06:43:24 CET
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);
Comment 14 Andrej Kacian 2018-01-16 15:19:38 CET
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. :)
Comment 15 Andrej Kacian 2018-01-16 15:26:22 CET
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.
Comment 16 Martin Väth 2018-01-16 17:04:50 CET
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?
Comment 17 Martin Väth 2018-01-16 17:27:24 CET
To be more precise:

The warnings/errors are printed (in the second call) *before*
the callback function list_dict_cb() is executed.
Comment 18 Paul 2018-01-16 17:41:34 CET
what version of enchant are you using?
Comment 19 Martin Väth 2018-01-16 19:12:28 CET
1.6.1
(Versions 2.1.0 and 2.1.1 are masked in gentoo due to incompatible API changes).
Comment 20 Martin Väth 2018-01-16 19:29:48 CET
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.