memory leaks and java ...

Thu Apr 3 09:22:00 GMT 2003

> "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.

But in this case you are supposed to use "-mthreads" while
linking in your program. This holds for C++ as well. The only flip
side to this is that the executables become dependent on the MinGW
"mingwm10" runtime DLL.
I hope Danny corrects me in this if this is not the correct
solution.
Ranjit.