[Bug libgcj/10746] [3.3/3.4 regression] [win32] garbage collection crash in GCJ

["hans_boehm at hp dot com" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10746



------- Additional Comments From hans_boehm at hp dot com  2003-09-09 00:03 -------
Subject: RE:  [3.3/3.4 regression] [win32] garbage colle
	ction crash in GCJ

I read the screen dump as saying that this died in _Jv_NewString because
it found that the object returned by _Jv_AllocString had (presumably)
both a zero data and zero boffset field.  Thus it was trying to copy
characters to a zero target address.

This is strange since _Jv_AllocString sets both of these fields to
nonzero values just before this.

It would be nice to get similar information like this for one or two more
crashes.  You could get somewhat better information by:

1) Building the collector with debug info, so that *GC_find_header(p)
prints a structure.  Failing that, it would be good to see the 50 or so
words following the value returned by GC_find_header.

2) Printing the contents of the heap object which appears to have been
clobbered with something like "x/10wx".

3) The value of GC_gc_no.  This is not a function.

4) The value of GC_arrays._words_allocd.  This probably requires debug info.

I assume this is reproducible on a uniprocessor without "hyperthreading"?

I just tried setting GC_PRINT_STATS in Windows 2000 with "set GC_PRINT_STATS=1"
from the Windows command line.  That does seem to work, at least with the
standalone collector compiled with VC++, though the output ends up in the
file "gc.log", not on the screen.  I suspect that means the other environment
variables will also do the right thing.

Hans
>