Hi, On Mon, Aug 16, 2010 at 03:45:55PM +0200, olafbuddenha...@gmx.net wrote:
> I'll check whether a NOP loop also causes a hang. And whether it > happens with another shell. Yes for both. I generated a backtrace from the hang with dash: #0 0x0104ef1c in swtch_pri () at /usr/src/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 #1 0x010507b4 in __spin_lock_solid (lock=0x11c18c0) at spin-solid.c:27 #2 0x010509ad in __mutex_lock_solid (lock=0x11c18c0) at mutex-solid.c:31 #3 0x010d1c1b in __mutex_lock (oldmem=0x805f560, bytes=92) at ../mach/lock-intern.h:89 #4 __libc_realloc (oldmem=0x805f560, bytes=92) at malloc.c:3814 #5 0x010c1e72 in _IO_vasprintf (result_ptr=0x1024a74, format=0x11ac528 "%s%s%s:%u: %s%sUnexpected error: %s.\n", args=0x1024650 "") at vasprintf.c:86 #6 0x010aacab in ___asprintf (string_ptr=0x1024a74, format=0x11ac528 "%s%s%s:%u: %s%sUnexpected error: %s.\n") at asprintf.c:37 #7 0x01086f98 in __assert_perror_fail (errnum=19, file=0x11a8718 "../sysdeps/mach/hurd/fork.c", line=466, function=0x11a874f "__fork") at assert-perr.c:62 #8 0x010fc510 in __fork () at ../sysdeps/mach/hurd/fork.c:466 #9 0x08050994 in ?? () #10 0x0804c359 in ?? () #11 0x0804b409 in ?? () #12 0x0804b6fc in ?? () #13 0x0804b409 in ?? () #14 0x08051c6c in ?? () #15 0x08051ea6 in ?? () #16 0x0107a81b in __libc_start_main (main=0x8051de0, argc=1, ubp_av=0x1024e44, init=0x80598c0, fini=0x80598b0, rtld_fini=0xef40 <_dl_fini>, stack_end=0x1024e3c) at libc-start.c:257 #17 0x080499a1 in ?? () No debugging symbols available for dash; but I hope they are not needed really... The problem seems to be some kind of deadlock in an error path within glibc's fork() handling. Any suggestion how to debug this? -antrik-
