dlopen() + spawn = bizarre crash in libnative... nobody else can reproduce

[XMPPwocky]

https://gist.github.com/XMPPwocky/81cf0033a44299ed288b

So I've been running into this for days, across several versions of rustc.

It appears to be a really nasty Heisenbug-

1. Nobody in #rust (cmr and a few other people) have this crash, despite same kernel, gcc, arch, and rustc.
2. It sometimes doesn't happen under gdb (only if you single step through it- it works fine then), and never happens under valgrind. Thus I suspect it's some sort of race condition.
3. Using libgreen prevents a crash- however, this may be because libgreen does not spawn any extra threads for this task.

Valgrind output with no crash below:

==10681== Memcheck, a memory error detector
==10681== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10681== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==10681== Command: ./main
==10681==
==10681== Warning: client switching stacks? SP change: 0xffeffffd0 --> 0xffedfbc98
==10681== to suppress, use: --max-stackframe=2114360 or greater
==10681== Syscall param read(buf) points to unaddressable byte(s)
==10681== at 0x4017AF7: read (in /usr/lib/ld-2.19.so)
==10681== by 0x40058D5: open_verify (in /usr/lib/ld-2.19.so)
==10681== by 0x4005BF7: open_path (in /usr/lib/ld-2.19.so)
==10681== by 0x40087F5: _dl_map_object (in /usr/lib/ld-2.19.so)
==10681== by 0x400C8A1: openaux (in /usr/lib/ld-2.19.so)
==10681== by 0x400EF03: _dl_catch_error (in /usr/lib/ld-2.19.so)
==10681== by 0x400CAFC: _dl_map_object_deps (in /usr/lib/ld-2.19.so)
==10681== by 0x4002F93: dl_main (in /usr/lib/ld-2.19.so)
==10681== by 0x4015BC4: _dl_sysdep_start (in /usr/lib/ld-2.19.so)
==10681== by 0x4004D6F: _dl_start (in /usr/lib/ld-2.19.so)
==10681== by 0x4000DC7: ??? (in /usr/lib/ld-2.19.so)
==10681== Address 0xffedfbca0 is on thread 1's stack
==10681==
==10681== Warning: client switching stacks? SP change: 0xffedfbca0 --> 0xffefffff8
==10681== to suppress, use: --max-stackframe=2114392 or greater
hi
Got: 1024
==10681==
==10681== HEAP SUMMARY:
==10681== in use at exit: 320 bytes in 2 blocks
==10681== total heap usage: 32 allocs, 30 frees, 5,614 bytes allocated
==10681==
==10681== LEAK SUMMARY:
==10681== definitely lost: 0 bytes in 0 blocks
==10681== indirectly lost: 0 bytes in 0 blocks
==10681== possibly lost: 288 bytes in 1 blocks
==10681== still reachable: 32 bytes in 1 blocks
==10681== suppressed: 0 bytes in 0 blocks
==10681== Rerun with --leak-check=full to see details of leaked memory
==10681==
==10681== For counts of detected and suppressed errors, rerun with: -v
==10681== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 3 from 3)

This is preventing me from using tasks in red (my text editor in Rust) because it uses dlopen and tasks in the same way.

[alexcrichton]

As @sfackler points out on IRC (props to him for finding this!), this is likely because the library has dlclose invoked on it, unmapping the memory, causing the segfault.

[sfackler]

We may want to reconsider DynamicLibrary's Drop impl. It caused some very confusing segfaults when I was working on the external syntax extension stuff when @trait destructors ran during cycle annihilation way after the libraries were unloaded. I think adding an opt-in by value close method (maybe even unsafe?) would be a better idea.

[alexcrichton]

I don't think that leaking resources is the best default, but having a by-value close operation that explicitly leaks the library would be more ok.

This is a very low-level implementation of a dynamic plugin, and I think its functions are unsafe for good reasons.