dlclose problem

[Jon K Hellan]

I am confused!

I am helping out with gnumeric, the Gnome spreadsheet. One feature of
this is "plugins". There are plugins for extension languages - Python
and Guile so far, and plugins for various file formats. Plugins are
dynamically linked with dlopen. The problem is that if initializing
the plugin fails, we close it with dlclose, but dlclose gives a
segmentation violation.

When plugins are loaded, the code looks roughly like this:

    handle = dlopen(filename, 0);
    if (!handle) goto error;
    discover init_plugin symbol
    if (!found) goto error;
    res = init_plugin();
    if (res != OK) goto error;
    return;

error:
    dlclose(handle);

init_plugin calls Py_Initialize, registers functions, etc. It
basically works.

But if something goes wrong in init_plugin, we close the plugin with
dlclose. My problem is that this causes a segmentation violation. When
run from a debugger, we get "Cannot access memory at address
0x406f2e34". The address is apparently where the python library was
linked in. I get this even if I immediately return from init_plugin,
without making python calls at all!

To isolate the problem, I made a test program with no application
code. All it does is dlopen the plugin, call init_plugin and
close. However, this program hangs in Py_Initialize, apparently
waiting for a lock. The backtrace is:
(gdb) bt
#0  0x4005d67a in sigsuspend () from /lib/libc.so.6
#1  0x40195703 in __pthread_lock () from /lib/libpthread.so.0
#2  0x4019306a in pthread_mutex_lock () from /lib/libpthread.so.0
#3  0x40195041 in flockfile () from /lib/libpthread.so.0
#4  0x400886bb in getc () from /lib/libc.so.6
#5  0x4015a4f6 in r_long ()
   from /usr/lib/gnumeric/plugins/0.47/libgnum_python.so
#6  0x4015ad1c in PyMarshal_ReadLongFromFile ()
   from /usr/lib/gnumeric/plugins/0.47/libgnum_python.so
#7  0x40157219 in check_compiled_module ()
   from /usr/lib/gnumeric/plugins/0.47/libgnum_python.so
#8  0x4015753d in load_source_module ()
   from /usr/lib/gnumeric/plugins/0.47/libgnum_python.so
#9  0x40157cfe in load_module ()
   from /usr/lib/gnumeric/plugins/0.47/libgnum_python.so
#10 0x401588d5 in import_submodule ()
   from /usr/lib/gnumeric/plugins/0.47/libgnum_python.so
#11 0x401584d3 in load_next ()
   from /usr/lib/gnumeric/plugins/0.47/libgnum_python.so
#12 0x40158162 in import_module_ex ()
   from /usr/lib/gnumeric/plugins/0.47/libgnum_python.so
#13 0x401582a3 in PyImport_ImportModuleEx ()
   from /usr/lib/gnumeric/plugins/0.47/libgnum_python.so
#14 0x40158100 in PyImport_ImportModule ()
   from /usr/lib/gnumeric/plugins/0.47/libgnum_python.so
#15 0x4015c403 in initsite ()
   from /usr/lib/gnumeric/plugins/0.47/libgnum_python.so
#16 0x4015c094 in Py_Initialize ()
   from /usr/lib/gnumeric/plugins/0.47/libgnum_python.so
#17 0x401391e0 in init_plugin (context=0x0, pd=0x804ae50) at python.c:309
#18 0x8048ce1 in main (argc=1, argv=0xbffff994) at plugin.c:49

Is this somehow related to the original problem?

When I linked the plugin code into the test program and just called
init_plugin, everything worked as expected.

To summarise, what we are doing is to dynamically link in code which
embeds python in gnumeric. Are there any suggestions as to what is
going wrong?

Jon