GC failure w/ THREAD_LOCAL_ALLOC ?

Fri Mar 22 11:00:00 GMT 2002

Jeff Sturm wrote:
 > On 2002年3月21日, Boehm, Hans wrote:
 >>You should be able to get the same effect with the GC_IGNORE_GCJ_INFO
 >>environment variable. (See boehm-gc/doc/README.environment.) I 
would still
 >>really like to track this down, though.
 >
 >
 > Thanks; that'll come in handy.
 >
 >
 >>2) The mark descriptor was clobbered. This can be a consequence of a
 >>premature object collection, due to any sort of collector bug. Since 
it's
 >>most likely to be overwritten by a pointer, this tends to make the object
 >>look VERY large.
 >
 >
 > I strongly suspect premature collection. Another clue is that I'm
 > getting files closed prematurely at random. That would happen if the
 > finalizer ran while the file is in use.
I've been seeing this as well and have been having difficulty tracking
it down. After seeing this message, I'm starting to think this may be
the cause.
I have an open FileInputStream to /dev/urandom. An "ls -l" of
"/proc/<pid>/fd" shows file descriptor 51 linked to /dev/urandom. Upon
a seemingly innocuous command in my app (doesn't touch anything near the
FileInputStream), file descriptor 51 no longer exists in /proc/<pid>/fd.
 Sometimes it exists as a socket instead.
When I turned on GC_PRINT_STATS, I noticed this seemingly inncouous 
command involves a garbage collection. When I started the application 
with an enormous initial heap size, the GC did not occur, and the fd for 
/dev/urandom stays around.
Hans, do you have enough information about the mark descriptor
clobbering to recommend a workaround even if you don't know exactly what
the problem is? For example, are you reasonably confident that building
with THREAD_LOCAL_ALLOC or USE_PTHREAD_SPECIFIC or something else will 
eliminate the problem (and not just "hide" it like GC_IGNORE_GCJ_INFO 
seems to do)?
thanks,
michael