The issue is that for the push/pop macro the old state of the macro (a cpp_macro reference) is stored. As this structure is handled by GC without a root, all get free'ed when garbage collection happens. This gc can lead to issues when such a saved node gets undefined and the node, which previously hold the cpp_macro reference, gets reused for a different macro. As the linked in the saved macro list isn't under control of gc and it doesn't have a gc root element, the stored reference gets invalid in such cases and can lead to segmentation faults due access to already free'ed memory.
*** Bug 45666 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugs/#need
(In reply to comment #2) > http://gcc.gnu.org/bugs/#need Since this is a bug in the preprocessor it is hard to get a preprocessed source that causes a bug.
Peeled this skin (164193) off and then blood comes running out.
(In reply to comment #4) > (In reply to comment #2) > > http://gcc.gnu.org/bugs/#need > > Since this is a bug in the preprocessor it is hard to get a preprocessed source > that causes a bug. > That's true. Interesting is that by doing preprocessed source out of it, result is correct. Just within compiler it makes troubles, as here garbage collector gets raised, which cleans up with store reference, as a root element for preprocessor tokens is missing to keep it alive.
(In reply to comment #4) > (In reply to comment #2) > > http://gcc.gnu.org/bugs/#need > > Since this is a bug in the preprocessor it is hard to get a preprocessed source > that causes a bug. > I think this is covered by: <blockquote>The only excuses to not send us the preprocessed sources are (i) if you've found a bug in the preprocessor,</blockquote> A testcase is always nice, even if not preprocessed.
(In reply to comment #4) > (In reply to comment #2) > > http://gcc.gnu.org/bugs/#need > > Since this is a bug in the preprocessor it is hard to get a preprocessed source > that causes a bug. > This is very odd, because I noticed, it could not produce this for example the 'just installed' gcc but the fault is only in xgcc. This can only means that something might not be correct in tree? or in the build process. However as it can show that this blocks the user 2 minutes from completing a GCC build. So why fail at the last minute...
GC issues normally don't show at different times depending on the layout of memory and such. Sometimes it depends on env variables being slightly different.
Program received signal SIGSEGV, Segmentation fault. gt_ggc_mx_cpp_macro (x_p=<value optimized out>) at gtype-desc.c:2078 2078 ((*x).params[i0]) ? HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).params[i0]))) : NULL; (gdb) bt #0 gt_ggc_mx_cpp_macro (x_p=<value optimized out>) at gtype-desc.c:2078 #1 0x00000000004caee5 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-c-decl.h:537 #2 0x00000000004cb0c3 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-c-decl.h:370 #3 0x00000000004cbcc8 in gt_ggc_mx_c_binding (x_p=<value optimized out>) at ./gt-c-decl.h:103 #4 0x00000000004cbcf2 in gt_ggc_mx_c_binding (x_p=<value optimized out>) at ./gt-c-decl.h:106 #5 0x00000000004caea6 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-c-decl.h:549
But too bad this file 'gtype-desc.c' is automatically generated at build time.
Can you try compiling it with --param ggc-min-expand=0 --param ggc-min-heapsize=0 ? Perhaps you'll trigger it then more reliably...
(In reply to comment #12) > Can you try compiling it with > --param ggc-min-expand=0 --param ggc-min-heapsize=0 > ? Perhaps you'll trigger it then more reliably... > Without it: GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 7ccff28a2de01cef50407f25bf137180 Program received signal SIGSEGV, Segmentation fault. gt_ggc_mx_cpp_macro (x_p=<value optimized out>) at gtype-desc.c:2078 2078 ((*x).params[i0]) ? HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).params[i0]))) : NULL; (gdb) bt #0 gt_ggc_mx_cpp_macro (x_p=<value optimized out>) at gtype-desc.c:2078 With it: GGC heuristics: --param ggc-min-expand=0 --param ggc-min-heapsize=0 Compiler executable checksum: 7ccff28a2de01cef50407f25bf137180 Program received signal SIGSEGV, Segmentation fault. gt_ggc_mx_cpp_macro (x_p=<value optimized out>) at gtype-desc.c:2078 2078 ((*x).params[i0]) ? HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).params[i0]))) : NULL; (gdb) bt #0 gt_ggc_mx_cpp_macro (x_p=<value optimized out>) at gtype-desc.c:2078 #1 0x00000000004caee5 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-c-decl.h:537 #2 0x00000000004cb0c3 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-c-decl.h:370 #3 0x00000000004cbcc8 in gt_ggc_mx_c_binding (x_p=<value optimized out>) at ./gt-c-decl.h:103 #4 0x00000000004cbcf2 in gt_ggc_mx_c_binding (x_p=<value optimized out>) at ./gt-c-decl.h:106 #5 0x00000000004caea6 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-c-decl.h:549 #6 0x00000000004cad62 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-c-decl.h:350 #7 0x00000000004cb00d in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-c-decl.h:413 #8 0x00000000004caf8c in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-c-decl.h:393 I see no diff, do you mean compile the code that caused crash or compile the xgcc or gcc over again?
Created attachment 21820 [details] testcase for problem As this test need more then on header, please extract it and compile then main.c to reproduce it. At least I was able to do this on linux64 by this testcase.
(In reply to comment #14) > Created an attachment (id=21820) [edit] > testcase for problem > > As this test need more then on header, please extract it and compile then > main.c to reproduce it. At least I was able to do this on linux64 by this > testcase. > Patch for it posted to ML. See http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01394.html
(In reply to comment #15) > (In reply to comment #14) > > Created an attachment (id=21820) [edit] > > testcase for problem > > > > As this test need more then on header, please extract it and compile then > > main.c to reproduce it. At least I was able to do this on linux64 by this > > testcase. > > > > Patch for it posted to ML. See > http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01394.html > Hi, it failed produce problem with attached testcase both the gcc and xgcc. I extracted it and compile with -c main.c
(In reply to comment #15) > (In reply to comment #14) > > Created an attachment (id=21820) [edit] > > testcase for problem > > > > As this test need more then on header, please extract it and compile then > > main.c to reproduce it. At least I was able to do this on linux64 by this > > testcase. > > > > Patch for it posted to ML. See > http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01394.html > Thanks a-lot Kai! This patch fixes ICE in PR45666.
Author: ktietz Date: Wed Sep 29 18:18:38 2010 New Revision: 164729 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164729 Log: 2010-09-29 Kai Tietz <kai.tietz@onevision.com> PR preprocessor/45362 * directives.c (cpp_pop_definition): Make static. (do_pragma_push_macro): Reworked to store text definition. (do_pragma_pop_macro): Add free text definition. (cpp_push_definition): Removed. * include/cpplib.h (cpp_push_definition): Removed. (cpp_pop_definition): Likewise. * internal.h (def_pragma_macro): Remove member 'value' and add new members 'definition', 'line', 'syshdr', 'sued' and 'is_undef'. * pch.c (_cpp_restore_pushed_macros): Rework to work on text definition and store additional macro flags. (_cpp_save_pushed_macros): Likewise. Modified: trunk/libcpp/ChangeLog trunk/libcpp/directives.c trunk/libcpp/include/cpplib.h trunk/libcpp/internal.h trunk/libcpp/pch.c
Fixed on trunk.