Re: open_issues/bash_busy-loop.mdwn

[Samuel Thibault]

olafBuddenhagen@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