Bug 3231 - segfault on unload python
Summary: segfault on unload python
Status: RESOLVED INVALID
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Plugins/Python (show other bugs)
Version: 3.11.0
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2014-07-23 16:37 UTC by Pierre Fortin
Modified: 2014-07-23 20:29 UTC (History)
0 users

See Also:


Attachments

Description Pierre Fortin 2014-07-23 16:37:00 UTC
Summary says it all :)
Comment 1 Pierre Fortin 2014-07-23 16:38:25 UTC
Argh!!  It segfaults on only one instance of CM...  :P
Debugging...
Comment 2 Pierre Fortin 2014-07-23 16:44:03 UTC
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
Comment 3 Pierre Fortin 2014-07-23 16:48:57 UTC
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
Comment 4 Pierre Fortin 2014-07-23 20:14:21 UTC
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"
Comment 5 Holger Berndt 2014-07-23 20:29:39 UTC
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? ;)

Note You need to log in before you can comment on or make changes to this bug.