bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fork() loses when thread self port's refcount is max'ed out


From: Roland McGrath
Subject: Re: fork() loses when thread self port's refcount is max'ed out
Date: Sat, 12 Oct 2002 22:37:52 -0400 (EDT)

The reason fork hangs is because it calls assert (which means a printf)
while holding lots of locks.  In particular it deadlocks on the dtable lock
in the backtraces you sent.

That is sort of a bug, in that an assert that managed to print out
something before crashing would be more helpful.  You could try sticking
some unlocks into the LOSE macro and see if that gets it to crash better.
If it does, I can put that into libc if you like.

But that use of assert_perror in fork.c was only ever intended for debugging
and should not be there in a "production system" (whenever that happens :-).
The LOSE macro in fork.c should just be "goto lose" and if that makes fork
do something that return a coherent error code without having leaked
anything, then that is a bug we should fix.  

It has heretofore always been more helpful in debugging either fork, or
whatever other thing was interacting weirdly to break it, to have the
assert than proper error handling for the error cases that modulo bugs
never happen unless there is total resource starvation.


As to the actual problems you saw, it is odd that the __thread_create calls
would be affected by thread-self references since that thread port is never
involved.  

Generally speaking, leaking send rights should be considered like leaking
memory and programs that leak any send rights are buggy.  This goes for the
thread and task send rights just like any other.  The mach_task_self macro
uses a variable containing a right gotten once at startup, and ordinarily
no urefs are added.  Calling mach_thread_self is usually pretty rare.
cthreads and libc always look at their stack data structures to find the
right they saved at thread creation, and don't add urefs.

For your example calling mach_thread_self 64k times, I think if you do that
and then random things like fork fail coherently with an error code, you
are just getting what you asked for.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]