Re: Finalizer deadlock

[Bryce McKinlay <mckinlay at redhat dot com>]

Gladish, Jacob wrote:

> This was proposed about two months ago:
>
>  
>
> > Yes, we could rewrite it using _Jv_CondWait/_Jv_CondNotify and other
> > thread primitives defined in the thread headers.
> >
> > I'm also not sure this peice of code in FinalizerThread is safe:
> > public static void finalizerReady ()
> > {
> >  synchronized (lock)
> >    {
> >  if (! thread_started)
> >    runFinalizers ();
> >
> > Isn't there a race here? Unlikely to happen, perhaps, but it seems like
> >    
> if >a finalizer needs to be run before the finalizer thread has finished
>  
>
> > starting, we'll try to run finalizers from the inside the GC's thread.
> >
> > Regards
> >
> > Bryce
> >
> >    
>
>
> Is this that case? The two threads are deadlocked. The finalizer is
> waiting for a monitor on the PlainSocketImpl. The internal data
> structures indicate that the second thread holds the mutex, but I don't
> see how that could be. The second thread is stuck waiting on the
> finalizer monitor. Could the bug you described somehow manifest itself
> into this state? I'm running with hash-sync off.
>  
What version of GCJ is this? This bug should be fixed by this patch:

http://gcc.gnu.org/ml/java/2004-07/msg00080.html

The finalizer thread should now not be holding any locks when 
_Jv_Runfinalizers is called. The patch is also in 3.4.2.

Regards

Bryce