loading shared objects at run time and recursive locks (was: Re: dynamic-linking)

[Marcus Brinkmann]

On Sat, Jun 02, 2001 at 03:37:11PM +0100, Paul Emsley wrote:
>         Yes, the process appears to wait for something, yes the
>       keyboard entries are echoed.  No, I can't interupt it with ^C or
>       suspend it either.

Ok.

>         Re: getting the source:
>         
>         How do I do that the proper way?  I tried:
> 
> $ apt-get source guile
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Bus error

Some people seem to get this, although apt-get works great for me.
That seens to be another bug.

> $ grep deb-src /etc/apt/sources.list
> deb-src http://http.us.debian.org/debian stable main contrib non-free

Yes, that's fine.

If apt doesn't work, you have to go to
http://http.us.debian.org/pool/g/guile and fetch the most
recent dsc, orig.tar.gz and diff.gz (if any) manually.  Then you can do

dpkg-source -x guile*dsc

to extarct the source. (Make sure you have dpkg-dev installed).

>       Regarding the attaching of gdb:  I couldn't make
>       anything out of it other than spin_lock_solid
>         seemed appropriate.

[BTW, it makes sense to check for other threads with info threads, although
I think there is only one thread here).

>       http://www.chem.gla.ac.uk/~paule/marcus

>From there:

(gdb) where
#0  0x13bec in swtch_pri () from /lib/ld.so
#1  0x13bba in spin_lock_solid () from /lib/ld.so
#2  0x11f8e in __mutex_lock_solid () from /lib/ld.so
#3  0x95a9 in add_dependency () from /lib/ld.so
#4  0x99db in _dl_lookup_symbol () from /lib/ld.so
#5  0xc921 in _dl_relocate_object () from /lib/ld.so
#6  0x11eee84 in dl_open_worker (a=0x10211a4) at dl-open.c:312
#7  0xe2bc in _dl_catch_error () from /lib/ld.so
#8  0x11ef02d in _dl_open (file=0x805faa8 "./guile-ncurses.so", mode=16912796,
    caller=0x10927b7) at dl-open.c:380
#9  0x10a1990 in dlopen_doit (a=0x1021294) at dlopenold.c:45
#10 0xe2bc in _dl_catch_error () from /lib/ld.so
#11 0x10a1466 in _dlerror_run (operate=0x10a195c <dlopen_doit>, args=0x1021294)
    at dlerror.c:130
#12 0x10a19d3 in __dlopen_nocheck (file=0x805faa8 "./guile-ncurses.so",
    mode=257) at dlopenold.c:62
#13 0x10927b7 in sys_dl_open (handle=0x805fad0,
    filename=0x805faa8 "./guile-ncurses.so") at ltdl.c:266
#14 0x1092d35 in tryall_dlopen (handle=0x10213d0,
    filename=0x805faa8 "./guile-ncurses.so") at ltdl.c:943
#15 0x1093bce in lt_dlopen (filename=0x805faa8 "./guile-ncurses.so")
    at ltdl.c:1369
#16 0x1093d5f in lt_dlopenext (filename=0x805faa8 "./guile-ncurses.so")
    at ltdl.c:1423
#17 0x10420f6 in sysdep_dynl_link (fname=0x805faa8 "./guile-ncurses.so",
    subr=0x1094dc3 "dynamic-link") at dynl.c:243
#18 0x104229e in scm_dynamic_link (fname=19554368) at dynl.c:358

>From here, there are only guile frames.  The dynamic linking seems to be
handled in scm_dynamik_link, with the meat of it (the os dependant part) in
sysdep_dynl_link.  Then there seem to be some more layers in guile
responsible to wrap up the dlopen call in frame #12.  From there on it's
glibc.  So we can safely say it is a glibc bug.  In fact, after some digging
in the ChangeLogs and poking around in the glibc source tree, we find in
sysdeps/mach/bits/libc-lock.h:

/* XXX until cthreads supports recursive locks */
#define __libc_lock_define_initialized_recursive __libc_lock_define_initialized
#define __libc_lock_init_recursive __libc_lock_init
#define __libc_lock_fini_recursive __libc_lock_fini
#define __libc_lock_trylock_recursive __libc_lock_trylock
#define __libc_lock_unlock_recursive __libc_lock_unlock
#define __libc_lock_lock_recursive __libc_lock_lock

Because cthreads does not support recursive locks, and we need one here (see
elf/rtld.c, _dl_load_lock), we get a dead lock.

In other words, loading shared objects at run time doesn't seem to be
supported (very well? at all?).

Could be called a glibc or GNU Mach bug.  I am moving this to
bug-hurd@gnu.org.

Thanks,
Marcus





-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de