bug#21587: Mac: Segfault when unloading shared object linked to libguile

bug#21587: Mac: Segfault when unloading shared object linked to libguile

[Wilhelm Schuster]

[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]

Hi,

I have a rather weird issue with guile on OSX Yosemite (10.10.5). The 
problem originally stems from weechat [1] which provides guile scripting 
through a dynamically loaded "plugin" (shared object). However, I was 
able to extract the problem into a smaller test program.

The basic run down: When I try to unload (using dlclose() ) a shared 
object that is linked to libguile after calling scm_init_guile() OR 
scm_with_guile(), a Segfault is triggered.

Here is my test case:

$ cat test.c
#include <stdio.h>
#include <dlfcn.h>

typedef int (*guile_func)(void);

int main (void) {
     void *guile = NULL;
     guile_func init_func = NULL;

     printf("Loading Guile... ");
     guile = dlopen("guile.so", RTLD_GLOBAL | RTLD_NOW);
     if (!guile) printf("Error!\n");
     else printf("Done!\n");

     printf("Trying to load \"init_guile\" ");
     init_func = dlsym(guile, "init_guile");
     if (!init_func) printf("Error!\n");
     else {
         printf("Done!\n");
         printf("Trying to run \"init_guile\"\n");
         init_func();
     }

     printf("Unloading Guile... ");
     fflush(stdout);
     dlclose(guile);
     printf("Done!\n");
}
$ cat guile.c
#include <libguile.h>

extern void init_guile(void);

void init_guile(void) {
     scm_init_guile();
}

When I compile and run the program I get the following output:

$ clang -g -shared -o guile.so guile.c $(pkg-config --cflags --libs 
guile-2.0)
$ clang -g test.c -o test
$ ./test
Loading Guile... Done!
Trying to load "init_guile" Done!
Trying to run "init_guile"
Unloading Guile... [1]    41550 segmentation fault  ./test

The expected output:

Loading Guile... Done!
Trying to load "init_guile" Done!
Trying to run "init_guile"
Unloading Guile... Done!

Here's an excerpt from the output when enabling dyld (dynamic linker) 
debugging information:

$ DYLD_PRINT_APIS=1 ./test
[...]
   dlopen(guile.so) ==> 0x7fbcc8e00000
Loading Guile... Done!
dlsym(0x7fbcc8e00000, init_guile)
Trying to load "init_guile" Done!
Trying to run "init_guile"
[...]
Unloading Guile... dlclose(0x7fbcc8e00000)
dlclose(), found unused image 0x7fbcc8e00000 guile.so
dlclose(), found unused image 0x7fbcc8c00170 libguile-2.0.22.dylib
dlclose(), found unused image 0x7fbcc8d04930 libgc.1.dylib
dlclose(), found unused image 0x7fbcc8e00140 libffi.6.dylib
dlclose(), found unused image 0x7fbcc8f00000 libunistring.2.dylib
dlclose(), found unused image 0x7fbcc8f00130 libgmp.10.dylib
dlclose(), found unused image 0x7fbcc8e001d0 libltdl.7.dylib
dlclose(), deleting 0x7fbcc8e00000 guile.so
dlclose(), deleting 0x7fbcc8c00170 libguile-2.0.22.dylib
dlclose(), deleting 0x7fbcc8d04930 libgc.1.dylib
dlclose(), deleting 0x7fbcc8e00140 libffi.6.dylib
[1]    41585 segmentation fault  DYLD_PRINT_APIS=1 ./test

I have attached a lldb debugging session with backtrace.

Cheers, Wilhelm Schuster.

[-- Attachment #2: lldb.log --]
[-- Type: text/plain, Size: 1062 bytes --]

$ lldb ./test
(lldb) target create "./test"
Current executable set to './test' (x86_64).
(lldb) run
Process 41607 launched: './test' (x86_64)
Loading Guile... Done!
Trying to load "init_guile" Done!
Trying to run "init_guile"
Unloading Guile... Process 41607 stopped
* thread #1: tid = 0x23e40d, 0x000000010003eb70, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10003eb70)
    frame #0: 0x000000010003eb70
error: memory read failed for 0x10003ea00
(lldb) thread backtrace 1
* thread #1: tid = 0x23e40d, 0x000000010003eb70, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10003eb70)
  * frame #0: 0x000000010003eb70
    frame #1: 0x00007fff5fc01cd3 dyld`dyld::removeImage(ImageLoader*) + 338
    frame #2: 0x00007fff5fc04fbc dyld`dyld::garbageCollectImages() + 823
    frame #3: 0x00007fff5fc0c3e8 dyld`dlclose + 134
    frame #4: 0x00007fff8f195808 libdyld.dylib`dlclose + 61
    frame #5: 0x0000000100000e97 test`main + 279 at test.c:48
    frame #6: 0x00007fff8f1965c9 libdyld.dylib`start + 1

bug#21587: Mac: Segfault when unloading shared object linked to libguile

[Wilhelm Schuster]

I forgot to include the link to the original issue:

[1]: https://github.com/weechat/weechat/issues/527

bug#21587: Mac: Segfault when unloading shared object linked to libguile

[Andy Wingo]

On Tue 29 Sep 2015 20:21, Wilhelm Schuster <wilhelm@wilhelm.re> writes:

> The basic run down: When I try to unload (using dlclose() ) a shared
> object that is linked to libguile after calling scm_init_guile() OR
> scm_with_guile(), a Segfault is triggered.

Hummmmmmmmmmmm!  Well, so this is quite tricky.  Loading Guile loads
Guile which might start threads (some helper threads behind the scenes
for finalization (see section on scm_set_automatic_finalization_enabled
in tha manual), perhaps a thread to listen for signals, and then the
garbage collector that we use (libgc) might start parallel marking
threads (though you can control that parameter too).

Guile doesn't really provide an interface to allow it to shut down
cleanly and I don't know if it can.  (I guess it could.)  However it
would take quite some amount of work and I don't see us doing it any
time soon.  In any case simply trying to dlclose() is never likely to
work, as you aren't synchronizing with Guile itself.

Sorry for the bad news!

Andy

bug#21587: Mac: Segfault when unloading shared object linked to libguile

[Andy Wingo]

Closing as not-a-bug given discussion below.  Please reply if you have
additional comments/etc.  Thanks.

Andy

On Fri 24 Jun 2016 14:32, Andy Wingo <wingo@pobox.com> writes:

> On Tue 29 Sep 2015 20:21, Wilhelm Schuster <wilhelm@wilhelm.re> writes:
>
>> The basic run down: When I try to unload (using dlclose() ) a shared
>> object that is linked to libguile after calling scm_init_guile() OR
>> scm_with_guile(), a Segfault is triggered.
>
> Hummmmmmmmmmmm!  Well, so this is quite tricky.  Loading Guile loads
> Guile which might start threads (some helper threads behind the scenes
> for finalization (see section on scm_set_automatic_finalization_enabled
> in tha manual), perhaps a thread to listen for signals, and then the
> garbage collector that we use (libgc) might start parallel marking
> threads (though you can control that parameter too).
>
> Guile doesn't really provide an interface to allow it to shut down
> cleanly and I don't know if it can.  (I guess it could.)  However it
> would take quite some amount of work and I don't see us doing it any
> time soon.  In any case simply trying to dlclose() is never likely to
> work, as you aren't synchronizing with Guile itself.
>
> Sorry for the bad news!
>
> Andy