Re: memory leaks and java ...

[Danny Smith <dannysmith at clear dot net dot nz>]

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

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.