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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
