memory leaks and java ...

[Adam Megacz]

"Ranjit Mathew" <rmathew4lists@hotmail.com> writes:
> Neither could I. I have built GCJ 3.3 without these
> "fake" function and variable and things seem to work
> just fine.

BEWARE!

This fixed an EXTREMELY hard to detect race condition where you would
throw an exception from one thread and it would get caught in another
thread.

Mingw EH works by allocating a per-thread object which holds a setjmp
buffer.  When you enter a try{} block, a setjmp() is written into that
buffer.  If CRT_MT isn't defined, or is equal to 0, the Mingw EH will
erroneously use the SAME setjmp() buffer for ALL threads.  BAD EVIL
BAD.  When you throw an exception, the EH longjmp()s to the buffer for
that thread.  Result: exceptions are always caught in the thread which
most recently entered a try block, which is *often* the current
thread, but not always.

I can't see anything in the cvs logs indicating that this bug on the
gcc side was ever fixed.

Please only remove this if you are absolutely certain that the above
bug will not occur again.  It would be best if you would write a test
case that spawns two threads; have one enter a try block, then have
the other enter a try block, then throw an exception in the first
thread and see if it is caught in the second thread (if so, FAIL).

Thanks for asking me about this.

I'm going to try to get back to gcj soon... I really need to implement
that link-time code pruning thing I posted earlier...

  - a