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: Thu, 11 Sep 2003 11:38:29 +0200
- Subject: Re: Help tracing an internal compiler error
- References: <85256D9D.0057B0FD.00@www.cimmetry.com>
> However, I just fired up the debugger again to see if I can get any
> useful information, and gdb is telling me that base is NULL... which
> could have something to do with it, if it isn't just gdb being confused by
> the optimization...
>
> (gdb) p base
> $7 = (page_entry ***) 0x0
No, I think this is what actually happens.
(gdb) where
#0 0x00254f58 in ggc_set_mark (p=0x0) at ../../gcc-3.3.1/gcc/ggc-page.c:525
#1 0x00037360 in gt_ggc_mx_lang_tree_node (x_p=0x2000000) at gtype-cp.h:109
#2 0x00037310 in gt_ggc_mx_cxx_binding (x_p=0xe93d8390) at gtype-cp.h:92
#3 0x00037ebc in gt_ggc_mx_lang_tree_node (x_p=0xe93d83a8) at gtype-cp.h:322
#4 0x00037b14 in gt_ggc_mx_lang_tree_node (x_p=0xe9317e48) at gtype-cp.h:222
#5 0x00037ab4 in gt_ggc_mx_lang_tree_node (x_p=0xe931e180) at gtype-cp.h:218
#6 0x00037ac4 in gt_ggc_mx_lang_tree_node (x_p=0xe2faf100) at gtype-cp.h:218
#7 0x00037d14 in gt_ggc_mx_lang_tree_node (x_p=0xe2fb70f8) at gtype-cp.h:258
#8 0x00037c68 in gt_ggc_mx_lang_tree_node (x_p=0x2) at gtype-cp.h:269
#9 0x00037c68 in gt_ggc_mx_lang_tree_node (x_p=0x1) at gtype-cp.h:269
#10 0x00037c68 in gt_ggc_mx_lang_tree_node (x_p=0x1) at gtype-cp.h:269
#11 0x00037c68 in gt_ggc_mx_lang_tree_node (x_p=0x1) at gtype-cp.h:269
#12 0x00037784 in gt_ggc_mx_lang_tree_node (x_p=0xe9319080) at gtype-cp.h:193
#13 0x00037884 in gt_ggc_mx_lang_tree_node (x_p=0xe3040280) at gtype-cp.h:182
#14 0x00037844 in gt_ggc_mx_lang_tree_node (x_p=0xe931f400) at gtype-cp.h:182
#15 0x00037874 in gt_ggc_mx_lang_tree_node (x_p=0xe931f380) at gtype-cp.h:182
The x_p=0x2000000 at frame #1 looks already bogus to me, so the struct
cxx_binding pointed to by x_p=0xe93d8390 is probably contaminated. It would
be interesting to find at which point it gets contaminated (in particular
whether it is already before the garbage collector is invoked).
> I think that's all the useful things I can think of doing at the moment...
> If you have any other suggestions, let me know...
Try maybe to play with the settings of the GC (see ggc-min-expand and
ggc-min-heapsize in the Optimize options).
--
Eric Botcazou