[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-03 21:48 -------
Subject: RE:  [3.3/3.4 regression] [win32] garbage colle
	ction crash in GCJ

Unfortunately, I'm not very familiar with mingw32.

I would assume that the real problem is occasional premature collection of an object.
It would be nice to verify that by debugging one of the crashes enough to convince
yourself that the crash is caused by an object that has been reclaimed.  Reclaimed
objects will normally be cleared except for the first word which is used as a link,
or they may have been reused for a different purpose.  Retrieving the class or anything
else by indirecting through the vtable may well generate a segmentation fault.

If p is the suspicious object, it would be nice to print

*GC_find_header(p), GC_is_marked(p), GC_gc_no

as well as the contents of p from the debugger.  If p doesn't look anything like the
intended type, GC_is_marked(p) is zero, and the header indicates the block was reclaimed
in this GC cycle, I would assume it was prematurely collected.

If premature collection is indeed the problem, there are a number of possible causes:

1) A generic collector bug.  (Seems unlikely, since it's apparently Windows specific.)

2) Bad root information for the platform, e.g. the collector doesn't quite see all the
thread stacks correctly.

3) Bad gcj generated collector information in the vtable.

4) A bug in the gcj-specific mark routines.

5) Some clever gcc optimization that hid a pointer from the GC.  (This is very unlikely,
since this is unoptimized.  But we might still be missing a register from the root set.
Is the problem more frequent with optimized code?)

It should be possible to mostly exclude (2) and certain collector bugs by setting the
environment variable GC_IGNORE_GCJ_INFO and checking whether the problem is still
reproducible.  (I've never verified that this works correctly on Windows, but I think
it should.  GC_DONT_GC and GC_PRINT_STATS may also be interesting.)

It would also be interesting to know if the collector does better if you build it with
USE_GENERIC_PUSH_REGS.  That should work well with gcc, and bypasses the current code
to identify relevant registers.

If that doesn't give much information, it would be really nice to get a test case that
fails after a predictable number of collections on a predictable object p.  If you get
to that stage, the procedure is to set a break point in GC_finish_collection(), and call
GC_is_marker() on every object in the reference chain that's used to reach p.  That
should identify which pointer isn't being followed by the collector.

If that's not possible, it would be good to learn as much as possible about the objects
that get collected too early, and how they can be reached from the stack.  Are they
usually directly pointed to by a stack-allocated variable?

Hans