Summary says it all :)
Argh!! It segfaults on only one instance of CM... :P Debugging...
pluginwindow.c:298:Creating plugins window... pluginwindow.c:427:called inc_lock (lock count 1) acpi_notifier.c:656:acpiprefs.file_path NULL acpi_notifier.c:656:acpiprefs.file_path NULL acpi_notifier.c:656:acpiprefs.file_path NULL plugin.c:288:removing /usr/local/lib/claws-mail/plugins/python.so rdeps hooks.c:90:unregisted hook 1 in 'compose_created' python_plugin.c:719:Python plugin done and unloaded. [1]+ Done claws-mail Segmentation fault This instance works: pluginwindow.c:298:Creating plugins window... pluginwindow.c:427:called inc_lock (lock count 1) plugin.c:288:removing /usr/local/lib/claws-mail/plugins/python.so rdeps hooks.c:90:unregisted hook 1 in 'compose_created' python_plugin.c:719:Python plugin done and unloaded. prefs.c:310:Found [Plugins_Common] prefs.c:310:Found [Plugins_GTK2] pluginwindow.c:77:called inc_unlock (lock count 0) When running with --debug, the instance that crashes outputs this message about once per second: acpi_notifier.c:656:acpiprefs.file_path NULL
Instances on host "prf": #1 local on main userid(pfortin) #2 "local" on second userid via "ssh pierre@prf" Strange that the local one crashes and the 2nd over ssh doesn't... HTH
Program received signal SIGSEGV, Segmentation fault. 0x00007f8cf227bd60 in new_threadstate () from /lib64/libpython2.7.so.1.0 (gdb) bt full #0 0x00007f8cf227bd60 in new_threadstate () from /lib64/libpython2.7.so.1.0 No symbol table info available. #1 0x00007f8cf227c60c in PyGILState_Ensure () from /lib64/libpython2.7.so.1.0 No symbol table info available. #2 0x00007f8cefb69252 in _filter_message () from /usr/lib64/python2.7/site-packages/_dbus_bindings.so No symbol table info available. #3 0x00007f8d0f75bde6 in dbus_connection_dispatch () from /lib64/libdbus-1.so.3 No symbol table info available. #4 0x00007f8d0f99de35 in message_queue_dispatch () from /lib64/libdbus-glib-1.so.2 No symbol table info available. #5 0x00007f8d0f244146 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 No symbol table info available. #6 0x00007f8d0f244498 in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0 No symbol table info available. #7 0x00007f8d0f24489a in g_main_loop_run () from /lib64/libglib-2.0.so.0 No symbol table info available. #8 0x00007f8d12a93127 in gtk_main () from /lib64/libgtk-x11-2.0.so.0 No symbol table info available. #9 0x00000000004d0f6a in main (argc=1, argv=0x7fff63964598) at main.c:1559 connection = 0xdf86e8 error = 0x0 userrc = 0xe96470 "/home/pfortin/.claws-mail/imapcache" mainwin = 0xe6e570 folderview = 0xea9810 icon = 0xe97050 crash_file_present = 0 num_folder_class = 2 asked_for_migration = 0 start_done = 0 plug_list = 0x0 never_ran = 0 mainwin_shown = 0 start = {tv_sec = 1406134151, tv_usec = 436652} end = {tv_sec = 1406134151, tv_usec = 728381} diff = {tv_sec = 0, tv_usec = 291729} timing_name = 0x6e443e "startup" __FUNCTION__ = "main"
I think what you're seeing is not a problem in the plugin itself, but in user code in python scripts that you let the plugin call. If your user code does something that cannot be reversed in a running process, there is nothing the plugin can do about that. I know this problem with registering on the D-Bus as it's done in the example startup script. In fact, judging from the backtrace and from the fact that your problem behaves differently whether you log in remotely via ssh or not makes it seem you're using exactly that. Marking this bug as invalid as I don't know what the plugin could do to heal this in the general case. As for the concrete D-Bus case, if somebody knows how the D-Bus registration that the startup script does can be undone in the shutdown script, I'd happily add it to the example. I'm aware that having an example script that causes problems on unload is not ideal. However, I find the use case of remote-control over D-Bus more interesting than the use case of unloading the plugin (who would ever want to do that, anyways? ;)