GC failure w/ THREAD_LOCAL_ALLOC ?

Wed Mar 27 12:48:00 GMT 2002

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