Re: memory leaks and java ...

["Ranjit Mathew" <rmathew4lists at hotmail dot com>]

> "Ranjit Mathew" <rmathew4lists at hotmail dot 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.