This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Crash when using dlmopen


I have a program that links against libSDL, which dlopens the aRts sound
server library ( which in turns dlopens various other

I'm experimenting with using an LD_PRELOAD module to force the first
dlopen of into a new namespace using dlmopen instead of
regular dlopen. That's because otherwise there are C++ symbol conflicts
between which is what the game uses and
which is what my copy of arts uses. The symbol versioning is not enough to
stop this (there is a bug in GCC bugzilla about it).

The first dlmopen seems to work OK judging by the LD_DEBUG traces, but
when libartsc (now in namespace 1) tries to dlopen another library it
crashes somewhere inside the dynamic linker. 

I tried to get a backtrace of this crash, the best I could get was one
that indicated the crash happened inside dlopen_doit, which is quite early
on and unlikely to be the real source of the bug. GDB was totally useless,
it seems completely broken on FC4 - even with the debuginfo packages
installed it does not give a real backtrace of most apps I try it with. I
had to use catchsegv and valgrind instead.

Does anybody have some ideas on why this might crash? Am I mis-using the

Also, I tried using RTLD_DEEPBIND as I thought that would be similar to
grouped fixup as implemented on Solaris. But it seems that this option
does not do what I thought it did - symbols are still bound back to the
original binary even though the executable is not "deeper" in the tree
than that library.

Can anybody explain why RTLD_DEEPBIND is not doing as I expected?

thanks -mike

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]