Description of problem: For an example, when compiling KDE from SVN Trunk, sometimes compilation will hang, and the only process left from that job is cc1plus. When it is in this "hung" position, it consistently takes 25% of one of my four cores. If I don't kill cc1plus, it will keep consuming my memory. I have a 2GHZ QuadCore system with 8gigs of RAM, and I have seen cc1plus take up all of my available RAM... Version-Release number of selected component (if applicable): gcc-c++-4.4.2-7.fc12.x86_64 How reproducible: Right now, if I go back to the source directory for kdepim and type "cmakekde" at about 80% completion it will hang. It does it on other projects. I'm just picking on that one... Steps to Reproduce: 1. Run "cmakekde" in the kdepim source directory 2. Wait... 3. Actual results: Compiling hangs, and I end up with a cc1plus process consuming 25% of one core, and it continues to consume more and more memory until I stop it. Expected results: The project should just continue to build and install, without hanging, and without cc1plus consuming 25% of one of my four cores, eating more and more memory, and producing absolutely no results. Additional info: I'm ready and willing to give you any additional info you will need. At least you can give me something to take back to upstream KDE, if this isn't a gcc issue. Also, my problem is very similar to this one: https://bugzilla.redhat.com/show_bug.cgi?id=503816 But in my case, I never get an error message. It just hangs there until I kill it.
If you're trying to compile kdelibs/khtml/svg, then it's var tracking coming large amounts of ram (meh, I thought we had reported this, but can't seem to find it right now). Workaround, build using -fno-var-tracking-assignments
using -fno-var-tracking-assignments allowed me to work around this issue when building globalsettings_base.o from kdepim/kmail
Same here. In my case, I had not had issues with kdepim, but I had had issues with a few other KDE Trunk modules, as well as a few non-KDE projects that use cc1plus. The following line is a workaround to this issue: -DCMAKE_CXX_FLAGS="-fno-var-tracking-assignments" -DCMAKE_BUILD_TYPE=custom \
*** This bug has been marked as a duplicate of bug 538233 ***