memory leaks and java ...

Thu Apr 3 09:46: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.
>
Yes that's right. We need a DLL in there to notify when thread
terminates so we can do EH cleanup. (When thread terminates it calls
DllMain with second arg set to DLL_THREAD_DETACH, and that's when we
call the TLS cleanup. Likewise when precess detaches). To see whats
going on build mingwm10.dll with -DDEBUG.
Danny
> Ranjit.