More information on JNI Win32 heap corruption

Jeff Sturm jsturm@one-point.com
Fri May 23 17:00:00 GMT 2003


On Fri, 23 May 2003, Ranjit Mathew wrote:
> > I reported a heap corruption issue w/Suns javax.comm serial
> > port stuff, but I gather that I have a better chance of getting
> > response if I have a testcase that can be run under Linux.
>
> I must mention that I'm able to consistently reproduce
> your problem via the attachment on the bug report. However,
> it's beyond my current set of skills to figure out the
> cause of the problem, beyond vaguely suggesting that the
> GC is getting hosed. :-(

This is PR java/10919 we're talking about?

Looks to me like it dies in the MSVCRT heap, and has nothing to do with
the GC.

    warning: HEAP: Free Heap block 68a030 modified at 68a05c after it was
    freed

This message probably comes from MSVCRT.DLL.

It would be nice if memory allocated by JNI could be GC'ed.  Unfortunately
there is no way to guarantee pointers returned by GetStringUTFChars et al
will be visible to the collector.  (Yet another reason I avoid JNI at all
costs.  I know there must be bugs in our jni.cc based on my experiences
with Oracle OCI8 drivers, but they can be fiendishly difficult to debug.)

If you choose to debug this, you really need to find the caller(s) that
malloc/free'd memory before the crash.  A debugging malloc library like
ElectricFence might be helpful.  I don't know of one for Win32.

You could also try a replacment javax.comm library, one preferably
with source code.

Jeff



More information about the Java mailing list