/usr/local/bin/g++ -DHAVE_CONFIG_H -I. -I.. -I../ -DHAVE_CONFIG_H -DMAPNIK_DEBUGinclude -ggdb -O1 -DDEBUG -pg -DMAPNIK_DEBUG -I/usr/include/libpng12 -I/usr/include/freetype2 -I/media/NewFoundSpace/2010/01/mapnik/agg/include -I/usr/local/include -I/usr/include/libxml2 -D_REENTRANT -I/usr/include/cairomm-1.0 -I/usr/include/cairo -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I../include -save-temps -MT libmapnik_la-filter_factory.lo -MD -MP -MF .deps/libmapnik_la-filter_factory.Tpo -c src/filter_factory.ii g++: Internal error: Killed (program cc1plus) Please submit a full bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
Please provide all the required information, in particular a pre-processed file. See this page for details: http://gcc.gnu.org/bugs/#report
Also make sure to include the PCH from the toplevel source file and not from some header.
Created attachment 19667 [details] precompiled headers /usr/local/bin/g++ -DHAVE_CONFIG_H -I. -I.. -I../ -DHAVE_CONFIG_H -DMAPNIK_DEBUGinclude -ggdb -O1 -DDEBUG -pg -DMAPNIK_DEBUG -I/usr/include/libpng12 -I/usr/include/freetype2 -I/media/NewFoundSpace/2010/01/mapnik/agg/include -I/usr/local/include -I/usr/include/libxml2 -D_REENTRANT -I/usr/include/cairomm-1.0 -I/usr/include/cairo -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I../include -save-temps -MT libmapnik_la-filter_factory.lo -MD -MP -MF .deps/libmapnik_la-filter_factory.Tpo -c src/filter_factory.ii g++: Internal error: Killed (program cc1plus) Please submit a full bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 326 bytes, done. Total 3 (delta 2), reused 0 (delta 0) To git@github.com:h4ck3rm1k3/MapNickAutotools.git 1ae752a..6803b1b master -> master
Sorry that is not the precompiled header, but the preprocessed, all you need to get the crash i hope.
We are still missing the SVN Rev of the GCC 4.5 you are using and how you built it.
Which GCC version are you using? The preprocessed source does not use a precompiled header. Compiling the file works ok for me with GCC 4.4.
got it again after make clean, maybe it ran out of memory: mdupont@introspector-desktop:/media/NewFoundSpace/2010/01/mapnik$ gunzip src/filter_factory.ii.gz mdupont@introspector-desktop:/media/NewFoundSpace/2010/01/mapnik$ /usr/local/bin/g++ -DHAVE_CONFIG_H -I. -I.. -I../ -DHAVE_CONFIG_H -DMAPNIK_DEBUGinclude -ggdb -O1 -DDEBUG -pg -DMAPNIK_DEBUG -I/usr/include/libpng12 -I/usr/include/freetype2 -I/media/NewFoundSpace/2010/01/mapnik/agg/include -I/usr/local/include -I/usr/include/libxml2 -D_REENTRANT -I/usr/include/cairomm-1.0 -I/usr/include/cairo -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I../include -save-temps -MT libmapnik_la-filter_factory.lo -MD -MP -MF .deps/libmapnik_la-filter_factory.Tpo -c src/filter_factory.ii g++: Internal error: Killed (program cc1plus) Please submit a full bug report. See <http://gcc.gnu.org/bugs.html> for instructions
Subject: Re: gcc segfaults on gch /usr/local/bin/c++ --version c++ (GCC) 4.5.0 20100113 (experimental) Copyright (C) 2010 Free Software Foundation, Inc. On Wed, Jan 20, 2010 at 9:01 PM, rguenth at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-20 20:01 ------- > Which GCC version are you using? The preprocessed source does not use > a precompiled header. Compiling the file works ok for me with GCC 4.4. > > > -- > > rguenth at gcc dot gnu dot org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > GCC target triplet| |i?86-*-* > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42814 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. >
With unoptimized trunk I see us blowing the stack during garbage-collecting. Note that we have a load of templates in this testcase and we walk them in unfortunate order. (gdb) #79368 0x0835b9fb in ggc_collect () at /home/richard/src/trunk/gcc/ggc-page.c:1962 1962 ggc_mark_roots (); ugh. We reach stuff from the function decl type. 400 gt_ggc_m_9tree_node ((*x).generic.type.size_unit); (gdb) #79358 0x0828fdc9 in gt_ggc_mx_lang_tree_node (x_p=0xb772f378) at ./gt-cp-tree.h:163 163 gt_ggc_m_9tree_node ((*x).generic.int_cst.common.type); (gdb) #79357 0x0829106b in gt_ggc_mx_lang_tree_node (x_p=0xb7743000) at ./gt-cp-tree.h:398 398 gt_ggc_m_9tree_node ((*x).generic.type.values); hmm ... #79349 0x0829115c in gt_ggc_mx_lang_tree_node (x_p=0xa83ff180) at ./gt-cp-tree.h:417 417 gt_ggc_m_9tree_node ((*x).generic.type.name); (gdb) #79348 0x08290cb9 in gt_ggc_mx_lang_tree_node (x_p=0xa8400138) at ./gt-cp-tree.h:355 355 gt_ggc_m_9tree_node ((*x).generic.type_decl.common.common.common.common.common.context); (gdb) #79347 0x0829106b in gt_ggc_mx_lang_tree_node (x_p=0xa83ff000) at ./gt-cp-tree.h:398 398 gt_ggc_m_9tree_node ((*x).generic.type.values); (gdb) #79346 0x08290229 in gt_ggc_mx_lang_tree_node (x_p=0xa84003a8) at ./gt-cp-tree.h:228 228 gt_ggc_m_9tree_node ((*x).generic.decl_non_common.common.common.common.common.common.type); (gdb) #79345 0x0829121c in gt_ggc_mx_lang_tree_node (x_p=0xa83ff420) at ./gt-cp-tree.h:425 425 gt_ggc_m_9lang_type ((*x).generic.type.lang_specific); (gdb) #79344 0x08292154 in gt_ggc_mx_lang_type (x_p=0xa83fdaa0) at ./gt-cp-tree.h:713 713 gt_ggc_m_9tree_node ((*x).u.c.template_info); hmm - we reach templates via integer constants ...
Subject: Re: gcc segfaults on gch so I am thinking about a way to wrap the existing templates that I use. there must be a way to reduce the size of the gch by specifing a list of classes we use. that would reduce the build size. this boost lib takes forever to process. We only use %1 of it at a time. There has got to be a way to precompile all these templates. A nice fine grained, for each header, external pch database for stl and boost would make working with them fun again. I have been experimenting with grouping the headers into groups of common dependencies. Basically I made a type level dependency tree that is sliced up into pools of common types and topologically sorted so that we can compile the the gch files in the right order and include the previous gch. I would consider putting some time into helping make the gch better if you give me direction. mike On Wed, Jan 20, 2010 at 9:47 PM, rguenth at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #10 from rguenth at gcc dot gnu dot org 2010-01-20 20:47 ------- > With unoptimized trunk I see us blowing the stack during garbage-collecting. > Note that we have a load of templates in this testcase and we walk them in > unfortunate order. > > (gdb) > #79368 0x0835b9fb in ggc_collect () > at /home/richard/src/trunk/gcc/ggc-page.c:1962 > 1962 ggc_mark_roots (); > > > ugh. We reach stuff from the function decl type. > > 400 gt_ggc_m_9tree_node ((*x).generic.type.size_unit); > (gdb) > #79358 0x0828fdc9 in gt_ggc_mx_lang_tree_node (x_p=0xb772f378) > at ./gt-cp-tree.h:163 > 163 gt_ggc_m_9tree_node ((*x).generic.int_cst.common.type); > (gdb) > #79357 0x0829106b in gt_ggc_mx_lang_tree_node (x_p=0xb7743000) > at ./gt-cp-tree.h:398 > 398 gt_ggc_m_9tree_node ((*x).generic.type.values); > > hmm ... > > #79349 0x0829115c in gt_ggc_mx_lang_tree_node (x_p=0xa83ff180) > at ./gt-cp-tree.h:417 > 417 gt_ggc_m_9tree_node ((*x).generic.type.name); > (gdb) > > #79348 0x08290cb9 in gt_ggc_mx_lang_tree_node (x_p=0xa8400138) > at ./gt-cp-tree.h:355 > 355 gt_ggc_m_9tree_node > ((*x).generic.type_decl.common.common.common.common.common.context); > (gdb) > #79347 0x0829106b in gt_ggc_mx_lang_tree_node (x_p=0xa83ff000) > at ./gt-cp-tree.h:398 > 398 gt_ggc_m_9tree_node ((*x).generic.type.values); > (gdb) > #79346 0x08290229 in gt_ggc_mx_lang_tree_node (x_p=0xa84003a8) > at ./gt-cp-tree.h:228 > 228 gt_ggc_m_9tree_node > ((*x).generic.decl_non_common.common.common.common.common.common.type); > (gdb) > #79345 0x0829121c in gt_ggc_mx_lang_tree_node (x_p=0xa83ff420) > at ./gt-cp-tree.h:425 > 425 gt_ggc_m_9lang_type ((*x).generic.type.lang_specific); > (gdb) > #79344 0x08292154 in gt_ggc_mx_lang_type (x_p=0xa83fdaa0) at ./gt-cp-tree.h:713 > 713 gt_ggc_m_9tree_node ((*x).u.c.template_info); > > > hmm - we reach templates via integer constants ... > > > -- > > rguenth at gcc dot gnu dot org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|WAITING |NEW > Ever Confirmed|0 |1 > Last reconfirmed|0000-00-00 00:00:00 |2010-01-20 20:47:22 > date| | > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42814 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. >
(In reply to comment #11) > Subject: Re: gcc segfaults on gch > > so I am thinking about a way to wrap the existing templates that I use. > there must be a way to reduce the size of the gch by specifing a list > of classes we use. that would reduce the build size. > > this boost lib takes forever to process. > We only use %1 of it at a time. There has got to be a way to > precompile all these templates. A nice fine grained, for each header, > external pch database for stl and boost would make working with them > fun again. > > I have been experimenting with grouping the headers into groups of > common dependencies. Basically I made a type level dependency tree > that is sliced up into pools of common types and topologically sorted > so that we can compile the the gch files in the right order and > include the previous gch. You can at most include a single gch file. > I would consider putting some time into helping make the gch better if > you give me direction. I think the issue is the following enum: template<class _Sp, class _Tp> struct __traitor { enum { __value = bool(_Sp::__value) || bool(_Tp::__value) };