Help tracing an internal compiler error

Eric Botcazou ebotcazou@libertysurf.fr
Wed Sep 10 07:37:00 GMT 2003


> I wasn't entirely sure what kind of a backtrace you wanted...  What I did
> was run cc1plus inside of gdb with the same args I saw when I did a gcc
> -v...  This does generate a segmentation fault, so I assume this is
> useful...  If not - I apologize for posting several thousand lines of
> nonsense!

Sorry for not being clear enough, but you got it.

> Program received signal SIGSEGV, Segmentation fault.
> 0x00254f58 in ggc_set_mark (p=0xea7b70f8) at
> ../../gcc-3.3.1/gcc/ggc-page.c:525 525    L2 = LOOKUP_L2 (p);
>
> *****
> To be honest --- I'm not sure why it is crashing here...  From what I can
> see, the value of p is sane, and from the definition I can see of
> LOOKUP_L2 everthing looks fine.
> *****

Note that lookup_page_table_entry is inlined in ggc_set_mark so the line 
numbering may not exactly match that of the original source code. I think 
the segfault actually occurs at the next line:

  return base[L1][L2];

> *****
> Here's the traceback...  It's pretty deep --- could this be a stack
> overflow?

That would be coherent with my previous remark: base is allocated in a page 
that the process isn't allowed to access.

The default maximum stack size is 8192K on Solaris 2.7 and 2.8, try to bump 
it to 16384K.

-- 
Eric Botcazou



More information about the Gcc-bugs mailing list