This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
weird GC problem
- To: java-discuss at sources dot redhat dot com
- Subject: weird GC problem
- From: Jeff Sturm <jeff dot sturm at appnet dot com>
- Date: Sat, 23 Dec 2000 02:49:22 -0500
I've been trying for a few days to track down a mysterious crash in some
Java code, using a recent gcc snapshot. So far I haven't produced a
simple test case... small classes never exhibit the problem.
In summary, a program that iteratively performs some calculations
(needing a considerable amount of heap) and prompts for console input
frequently aborts with:
java.io.IOException: Bad file descriptor
Increasing the initial heap size delays the error. Calling System.gc()
usually triggers the error immediately. Since I'm seeing this
IOException consistently instead of other random crashes, I began to
suspect finalization. Sure enough, if I disable finalization completely
by commenting out GC_finalize() in boehm-gc/alloc.c, the program appears
to run normally.
So it seems that FileDescriptor.in had been inadvertently finalized by
the GC, closing the native descriptor. Had it actually been collected
as well, I would expect to see other failures sooner or later, as the
vtable would be overwritten. But this isn't the case. The program runs
for many iterations and always produces the correct answer, once I
hacked alloc.c.
So my questions are:
1) Supposing that FileDescriptor.in is being properly marked by the GC,
what could cause a premature finalization?
2) Is anybody else noticing similar behavior?
3) Is there another possible explanation for these symptoms?
I'm running a recent snapshot on RH7 (x86).
--
Jeff Sturm
jeff.sturm@commerceone.com