Re: GC failure w/ THREAD_LOCAL_ALLOC ?

[Michael Smith <msmith at spinnakernet dot com>]

Boehm, Hans wrote:
> Can you put a breakpoint in close() to verify that the descriptor is being
> closed by a finalizer?
> 
> If you can repeat this, and the GC is responsible, and you can figure out
> which object is getting collected, a good thing to do is to put a breakpoint
> in GC_finish_collection() during the offending GC, and then invoke
> GC_is_marked() on all objects in the reference chain from the debugger, with
> the process still stopped in GC_finish_collection.  If you find a marked
> object pointing to an unmarked one, it would be good to know the results of 
> 
> print *GC_find_header(<last marked>)
> 
> If it's a gcj object, so would the mark descriptor.
> 
> I'm also suspicious that this is a completely separate problem, possibly
> outside the GC.

After a bit of investigation, I can confidently say that the GC is not 
collecting objects prematurely, causing my /dev/urandom file descriptor 
to get closed.

It turns out, I was hitting a double-close related to a failed Process 
exec, which had been fixed in CVS since I got my version.  I've pulled 
down the patches to natPosixProcess.cc, applied them to my local tree 
and my file descriptors are no longer disappearing unexpectedly.

thanks,
michael