On Wed, Oct 01, 2008 at 04:17:44PM -0500, Paul Fisher wrote: > Nicolas Williams wrote: > >Is NSPR installed on your system? > > Yep: > > >Does you application have a private > >copy of NSPR linked into it? > > Nope, the executable:
Use lari(1) with no options, just the executable name: $ lari /usr/local/lib/erlang/erts-5.6.4/bin/beam.smp This will produce "interesting" information. We're looking for stuff like: [2:0]: PL_ArenaFinish(): /local/tmp/VirtualBox/ROOT/opt/VirtualBox/VBoxXPCOM.so [2:0]: PL_ArenaFinish(): /usr/lib/mps/amd64/libplds4.so (I learned this from Rod Evans in the VBox case.) > and the dlopen'd library: Oh, run lari on any and all libraries that might get dlopen()ed. > $ file bld/solaris-5-11-x86_64-threaded-gcc/lib/libcoresrv.so.1.0 > bld/solaris-5-11-x86_64-threaded-gcc/lib/libcoresrv.so.1.0: ELF 64-bit > LSB dynamic lib AMD64 Version 1, dynamically linked, stripped $ lari bld/solaris-5-11-x86_64-threaded-gcc/lib/libcoresrv.so.1.0 > The really puzzling thing is that this seems to happen once, and then a > subsequent attempt to dlopen the library works without error. I tried > for a bit last night to create a small test case that demonstrated the > problem, but could not. The only thing that comes to mind is transient failure to mount something (which happens in the mirror mount case, where you get EBUSY when racing to trigger a mirror mount)... But that doesn't seem applicable here. Nico -- _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
