This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/12252] ICE on very large source file : GC problem?
- From: "mec at shout dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 13 Sep 2003 20:27:54 -0000
- Subject: [Bug c++/12252] ICE on very large source file : GC problem?
- References: <20030911203619.12252.warren_baird@cimmetry.com>
- Reply-to: 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=12252
------- Additional Comments From mec at shout dot net 2003-09-13 20:27 -------
I'm not an expert on this at all, but I have a suggestion.
Put a breakpoint inside ggc_collect about 10 lines in, after this expression:
if (G.allocated < allocated_last_gc + min_expand)
return;
timevar_push (TV_GC); /* BREAKPOINT HERE */
This breakpoint will get hit when the garbage collector is going to do some
actual work. (You can't just break on ggc_collect because most of the calls
take the early return without doing work).
Each time that breakpoint is hit, take a full stack trace. Then report those
stack traces. Attach all of them, not just the last one.
If this is a garbage collection bug, then one of the stack traces is likely show
some function that thinks it is safe from gc but is actually getting gc called.
I can't tell which function it will be -- that is for a real gcc hacker.
Also, someone let me know if this is actually helpful for garbage collection
bugs. My understanding is that it's useful but if I am mistaken I welcome a
correction.
Hope this helps,
Michael C