This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/12252] ICE on very large source file : GC problem?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]