Lock spidermonkey_drv.so in memory so NSPR thread cleanup code runs.

[jonmeredith]

Fixes SEGV under R15B.

Eventually tracked down using valgrind-build of beam and doing some digging.

Was erroring with

warning: Temporarily disabling breakpoints for unloaded shared library "/home/jmeredith/erlang_js/ebin/../priv/erlang_js_drv.so"

Program received signal SIGTRAP, Trace/breakpoint trap.
0x000000000ad60940 in ?? ()
(Gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <PENDING>          sm_eval
    breakpoint already hit 1 time

which was in the memory range that erlang_js_drv.so used to occupy. Info gathered before the breakpoint.

(gdb) info sh
From                To                  Syms Read   Shared Object Library
0x0000000004000af0  0x0000000004019704  Yes         /lib64/ld-linux-x86-64.so.2
0x0000000004a22510  0x0000000004a22778  Yes         /usr/local/valgrind-3.7.0/lib/valgrind/vgpreload_core-amd64-linux.so
0x0000000004c26810  0x0000000004c2bce8  Yes         /usr/local/valgrind-3.7.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so
0x0000000004e2fe10  0x0000000004e30688  Yes         /lib/libutil.so.1
0x0000000005032de0  0x00000000050339c8  Yes         /lib/libdl.so.2
0x0000000005239ef0  0x000000000527a7f8  Yes         /lib/libm.so.6
0x00000000054c9a20  0x00000000054e83e8  Yes (*)     /lib/libncurses.so.5
0x00000000057013e0  0x000000000570d388  Yes         /lib/libpthread.so.0
0x000000000591b190  0x000000000591e7d8  Yes         /lib/librt.so.1
0x0000000005b3f8c0  0x0000000005c52c60  Yes         /lib/libc.so.6
0x00000000072a6a90  0x00000000072a73e8  Yes (*)     /usr/lib/libsctp.so.1
0x000000000acdd1c0  0x000000000ad6f5e8  Yes         /home/jmeredith/erlang_js/ebin/../priv/erlang_js_drv.so

The address above was mapped to

(gdb) x _pt_thread_death
0xad60940 <_pt_thread_death>:   0x000001be

which is some thread cleanup code in NSPR.

Something must have changed about the order of library unloading for the R15 shutdown sequence as we haven't seen this on R14 or before to my knowledge.

The solution is to make the driver permanent and lock the shared object in memory with driver_lock_driver(port)

[slfritchie]

+1, bug be gone, looks like an appropriate use for driver_lock_driver(). At least one other person is using it, see http://erlang.org/pipermail/erlang-questions/2007-December/031863.html