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