RE: GCJ 3.3 crash with string handling reproduceable case

["Boehm, Hans" <hans_boehm at hp dot com>]

> -----Original Message-----
> From: Ranjit Mathew [mailto:rmathew4lists at hotmail dot com]
> 
> > The warnings don't look familiar to me.  Does anyone know what's
> generating them?
> 
> It turns out that the warnings were being generated by the DrMinGW
> debugger so we should ignore this.
> 
> BTW, I get the exact same error at the exact same location even with
> the latest 6.2alpha3 release!
That's what I would have guessed ...
> 
> I tried compiling it all using BCC 5.5, but BCC died out on
> multiple definition errors in gc_cpp.h (though it should not be...).
I was just discussing that with a non-gcj user.  It appears to be easily fixable, and will be fixed in 6.2alpha4.  Remove the definitions of operator delete with 2 void * parameters.  (I believe that according to the C++ standard those are necessary to handle the case of exceptions thrown in destructors.  The fact that BCC doesn't seem to recognize them suggest they won't do any good with that compiler anyway.  And none of this is used by gcj.)
> 
> Since GCC doesn't support Win32 Structured Exception Handling (SEH),
> the README.win32 document paints a pretty bleak picture for it.
> :-(
I've lost track of the current MingW configuration.  That may certainly be a problem, especially of libgcj is in a dynamic library.  Probably the right solution is to move in the direction of Jeff's old proposal (http://gcc.gnu.org/ml/java/2002-06/msg00252.html) to allow the collector to find gcj roots even if it can't rely on VirtualQuery.

I couldn't recognize anything in the stack trace that made it look like this sort of failure.  The usual symptom, if you attempt to trace from dynamic library roots, is that the marker tries to access roots that have asynchronously disappeared in the meantime.  If you ignore roots that you shouldn't be ignoring, you expect objects to be prematurely reclaimed.  Is that a possibility here?
> 
> 
> The Win32 code BTW looks very errr... "weird" what with every 
> #ifdef and
> its mother making it difficult to properly understand it. :-(
> 
My personal opinion is that ifdef's aren't any harder to read than if's, assuming they're similarly indented, and fit with the program structure.  I prefer them to duplicated code.  Unfortunately, this seems to be at odds with the usual GNU style of either avoiding them completely or not indenting them (why??).  I think that file suffers a bit from a mixture of the two.  And it just needs some cleaning up.

Hans