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 [EMAIL PROTECTED] Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
