This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Help tracing an internal compiler error
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: Warren_Baird at cimmetry dot com
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 10 Sep 2003 09:46:00 +0200
- Subject: Re: Help tracing an internal compiler error
- References: <85256D9C.005A33C0.00@www.cimmetry.com>
> 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