[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #11 from Marek Polacek --- Doesn't seem like a bug in the compiler.
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 Mike Jarvis michael at jarvis dot net changed: What|Removed |Added Severity|normal |minor --- Comment #10 from Mike Jarvis michael at jarvis dot net 2011-06-11 06:17:57 UTC --- Downgrade priority to minor, since gcc should probably just have a better error message, rather than a segmentation fault if that's possible. Something along the lines of the error message it emits when exceeding the heap memory: virtual memory exhausted: Cannot allocate memory
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 10:00:58 UTC --- Needs quite some more memory for me ... (doesn't fit in my 3GB box).
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-10 10:39:58 UTC --- you're gonna need a bigger boat compiles ok on a 64-bit box, physical memory usage nears 4GB
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #4 from Mike Jarvis michael at jarvis dot net 2011-06-10 14:02:45 UTC --- That's a bit odd. The final function in the .ii file consists of two function calls. If I delete either one of these, the compile succeeds and only uses about 1100M (RSIZE in top). So I would have thought that a successful compilation with both functions there would take around 2GB, not 4. However, on my machine, the compiler bombs out before even getting to 1GB memory usage. (Around 785M, as I mentioned.) But either way, my machine has 8GB physical memory, so that should be plenty even if it wants to use 4GB.
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-10 14:06:19 UTC --- a single 32-bit process won't be able to use that much
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #6 from Mike Jarvis michael at jarvis dot net 2011-06-10 21:04:59 UTC --- I figured out how to install a 64 bit version of g++ on my machine, and I also booted up the machine with 6 and 4 held down to get the 64 bit kernel. And this didn't help. I'm still getting the same Internal error: Segmentation fault. This time it got up to around 1300 MB memory usage before crashing (which of course could be at the same point in the compiling process, since I'm sure memory usage by g++ is different now). $ uname -a Darwin drl-dhcp42-064.sas.upenn.edu 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:16:10 PST 2011; root:xnu-1504.9.37~1/RELEASE_X86_64 x86_64 $ g++-4 -v -c TMV_TestSmallMatrixArith_6f.ii Using built-in specs. COLLECT_GCC=g++-4 COLLECT_LTO_WRAPPER=/sw64/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.7.0/4.5.2/lto-wrapper Target: x86_64-apple-darwin10.7.0 Configured with: ../gcc-4.5.2/configure --prefix=/sw64 --prefix=/sw64/lib/gcc4.5 --mandir=/sw64/share/man --infodir=/sw64/lib/gcc4.5/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw64 --with-libiconv-prefix=/sw64 --with-ppl=/sw64 --with-cloog=/sw64 --with-mpc=/sw64 --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.5 --enable-lto Thread model: posix gcc version 4.5.2 (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.7' '-v' '-c' '-shared-libgcc' '-mtune=generic' /sw64/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.7.0/4.5.2/cc1plus -fpreprocessed TMV_TestSmallMatrixArith_6f.ii -fPIC -quiet -dumpbase TMV_TestSmallMatrixArith_6f.ii -mmacosx-version-min=10.6.7 -mtune=generic -auxbase TMV_TestSmallMatrixArith_6f -version -o /var/folders/UU/UU2-eU61GFOx3d6RzbOM4U+++TI/-Tmp-//cc8rFRK8.s GNU C++ (GCC) version 4.5.2 (x86_64-apple-darwin10.7.0) compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.5.2 (x86_64-apple-darwin10.7.0) compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 43c0c50b4e3b4ab818a4452c96b3c3df g++-4: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-10 21:10:16 UTC --- does 'ulimit -a' show any limit on memory size? obviously it would be good if gcc didn't use so much memory, but I did verify that given a sufficiently beefy machine (64-bit, 24GB RAM) gcc 4.5.2 can compile the .ii, so I think your segfault is due to running out of memory rather than hitting a null pointer deference or other bug in gcc itself
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #8 from Mike Jarvis michael at jarvis dot net 2011-06-10 21:26:59 UTC --- $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 266 virtual memory (kbytes, -v) unlimited Should I try changing any of these? stack size? Also, I don't really understand why you think it's a memory issue, when it is not getting anywhere close to using 8GB, my machine's physical memory, before it crashes. Although, I do understand that it's hard to guess what the problem might be when you haven't been able to confirm the bug on one of your machines.
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #9 from Mike Jarvis michael at jarvis dot net 2011-06-10 21:47:37 UTC --- That worked. So I guess g++ is exceeding the stack limit and crashing, not the heap memory. $ ulimit -aH core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) unlimited pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 65532 cpu time (seconds, -t) unlimited max user processes (-u) 532 virtual memory (kbytes, -v) unlimited $ ulimit -s 65532 $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 65532 cpu time (seconds, -t) unlimited max user processes (-u) 266 virtual memory (kbytes, -v) unlimited $ g++-4 -c TMV_TestSmallMatrixArith_6f.ii $ I guess this is still a bug, so I won't close it. But I don't know how easy it would be for gcc to tell when it is going to exceed the stack limit and modify behavior accordingly. Or at least to give a useful error message that the stack size needs to be increased. But regardless, thank you for your help in diagnosing the problem. (And yes, it did end up using close to 4 GB.)
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #1 from Mike Jarvis michael at jarvis dot net 2011-06-10 00:54:35 UTC --- I should add that g++ version 4.4.4 also fails to work with this code. It gives the same Internal error: Segmentation fault that 4.5.2 gave. But g++ 4.0.1 and 4.2.1 do work. Well, they don't actually compile this .ii file (I get errors regarding some stl calls, things in the std namespace, and such), but they both compile the original source code without any problem.
