olafbuddenha...@gmx.net, le Wed 18 Aug 2010 14:38:34 +0200, a écrit : > 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
On seeing this, I got to wonder whether we have some protection against forking while this mutex being already held by another thread. Probably worth checking. > #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 And then this: there's actually a bug happening during the fork call: there are thread_refs, and for some reason the child is not able to get them too. > 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? The two paths: whether we have protection against concurrency between the allocator mutex being held and fork, and why the port_mod_refs call doesn't work. Samuel
