Re: possible bug sighting - exit hang

[Hui Huang]

Wolfram-

> ... if this is really the stripped-down version of the Java code I'd
> suggest that you consider either creating the thread detached or
> joining with it.

Thanks for the suggestion. No, it's not a stripped-down version of VM
code. In fact, it is a native thread created by user program that is
allocating memory when the VM shuts down. We control the shutdown path 
for all threads that are known to the VM, but can't do anything for 
native threads.

                   Falling off the end of main lets all threads that
> are still running just 'evaporate' at some unspecified time with
> absolutely no control over their resources.

I absolutely agree here.

> 
> I believe this is _very_ rarely what you want.
> 
> > The problemetic code is in pthread.c, pthread_onexit_process
> > (glibc-2.2.4):
> ...
> > Line 796 needs to grab malloc lock and it may hang if one of the threads
> > is killed when it's still holding the lock. The test code works fine
> > with
> > line 796 commented out. I don't see why you need to free the manager
> > thread
> > stack, the process is gone, there is no memory leak to worry about.
> 
> I disagree, this should be fixed in another way.  There are other
> locks such as file locks that are potentially affected in this rare
> case.  I think we should perform the equivalent of
> pthread_atfork_prepare() in the main thread when falling of the end of
> main().  Then all present and future libc locks would be kept and the
> remaining threads could be terminated safely.  I'll prepare a patch if
> no-one else beats me to it.

Good to know there is a way to prevent that. You might also want to look 
at the handling of exit(). That could cause hang too. Probably you
should 
grab libc locks before sending REQ_PROCESS_EXIT to the manager thread. 
Just some random thoughts.

regards,
-hui