Hi, unfortunately it's hard for me to tell whether this is the same as any of the other segfault bugs, so I'll have to ask you to determine that for yourselves. $ g++ -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) $ g++ -c -o bugtest.out -O2 bugtest.ii projects/odete/bugtest.cpp: In member function ‘bool tBspTree2D::Intersect(const tVec2f&, const tVec2f&, tVec2f&, double) const [with bool oriented = true]’: projects/odete/bugtest.cpp:81: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. I am about to attach bugtest.ii.
Created attachment 20443 [details] bugtest.ii to reproduce the segfault. This is the preprocessed source file leading to the segfault, created using g++ -save-temps and gzip.
The following is a list of changes to the code, each of which makes the segfault disappear: - Remove the max_len parameter from tBspTree2D::Intersect() and replace its use by a constant - Remove lines 44931 through 44936 from bugtest.ii - Remove line 44955 (bool intersect_recursive = bsp->Intersect<true>(o, dir, pr);) I hope I didn't miss any important information you might still need. Best wishes, Jan
The file bugtest.ii compiles successfully in gcc-4.3.4 (unfortunately I can't go back to 4.3 though). $ g++-4.3 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.4-5ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.4 (Ubuntu 4.3.4-5ubuntu1)
works for me with 4.4.2 and higher - could you be running out of memory?
I don't think it's the memory, I've got 4 GB at my disposal (32-Bit system with PAE kernel), and it doesn't seem to take up much memory: $ uname -a Linux delorean 2.6.31-20-generic-pae #58-Ubuntu SMP Fri Mar 12 06:25:51 UTC 2010 i686 GNU/Linux $ free total used free shared buffers cached Mem: 3921840 2022788 1899052 0 380908 1064988 -/+ buffers/cache: 576892 3344948 Swap: 4294040 0 4294040 $ strace -emmap2,mremap,brk,setrlimit g++ -c -o bugtest.out -O2 bugtest.ii brk(0) = 0x97a3000 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb781d000 mmap2(NULL, 139729, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77fa000 mmap2(NULL, 1329512, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb76b5000 mmap2(0xb77f4000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13e) = 0xb77f4000 mmap2(0xb77f7000, 10600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb77f7000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb76b4000 brk(0) = 0x97a3000 brk(0x97c4000) = 0x97c4000 mmap2(NULL, 1085056, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb75ab000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb781c000 mmap2(NULL, 256316, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb756c000 mmap2(NULL, 26048, PROT_READ, MAP_SHARED, 3, 0) = 0xb7816000 mmap2(NULL, 52, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7815000 projects/odete/bugtest.cpp: In member function ‘bool tBspTree2D::Intersect(const tVec2f&, const tVec2f&, tVec2f&, double) const [with bool oriented = true]’: projects/odete/bugtest.cpp:81: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. --- SIGCHLD (Child exited) @ 0 (0) --- I've also confirmed the same behavior on another system running the same OS and gcc version, so my RAM is probably OK. I'll try it with >=4.4.2 later.
A test with a g++-4.4.2 I built myself has the same problem: $ g++-4.4.2 -c -o bugtest.out -O2 bugtest.ii projects/odete/bugtest.cpp: In member function ‘bool tBspTree2D::Intersect(const tVec2f&, const tVec2f&, tVec2f&, double) const [with bool oriented = true]’: projects/odete/bugtest.cpp:81: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. $ g++-4.4.2 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../gcc-4.4.2/configure --prefix=/home/oberlaen/local/stow/gcc-4.4.2/ --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++ --enable-shared --disable-multiarch --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --program-suffix=-4.4.2 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-multilib --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.2 (GCC) Jonathan, since 4.4.2 worked for you -- got any idea what could be different in my case? Am I doing something wrong? I installed 4.4.2 with the regular ./configure <options as above>; make; make install (into my $HOME/local), is there any risk of a mixup between 4.4.1 and 4.4.2? Thanks in advance for your help. I'll try 4.4.3 next...
4.4.3 gives me the same problem, I'm starting to think I'm really doing something wrong. $ g++-4.4.3 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../gcc-4.4.3/configure --prefix=/home/oberlaen/local/stow/gcc-4.4.3/ --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++ --enable-shared --disable-multiarch --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --program-suffix=-4.4.3 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-multilib --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.3 (GCC)
Just tested 4.5.0, which did not crash. $ g++-4.5.0 -c -o bugtest.out -O2 bugtest.ii $ g++-4.5.0 -v Using built-in specs. COLLECT_GCC=g++-4.5.0 COLLECT_LTO_WRAPPER=/home/oberlaen/local/stow/gcc-4.5.0/libexec/gcc/i486-linux-gnu/4.5.0/lto-wrapper Target: i486-linux-gnu Configured with: ../gcc-4.5.0/configure --prefix=/home/oberlaen/local/stow/gcc-4.5.0/ --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++ --enable-shared --disable-multiarch --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --program-suffix=-4.5.0 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-multilib --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu --with-mpc=/home/oberlaen/local Thread model: posix gcc version 4.5.0 (GCC) Also, all the 4.4.x versions work fine if I replace -O2 with -O1. The question remains, what is going wrong with my various 4.4.x tests, and why did it work for Jonathan? I've circumvented the problem in my piece of software for now by going from -O2 to -O1, as I don't feel like rebuilding everything against 4.5 just yet. :) But at least according to my tests, the problem is present in all 4.4 releases. Can anyone else reproduce the error? Thanks and best regards, Jan
I tested on an x86_64 box (with -m32 because your preprocessed source was made on a 32bit box so it was necessary) so I definitely have a lot more memory available I'm still thinking it's a problem with running out of memory, PAE doesn't increase the total memory available to a single process
(In reply to comment #9) > I'm still thinking it's a problem with running out of memory, PAE doesn't > increase the total memory available to a single process How would I find out if that is the issue? The numbers reported by my strace output seem harmless to me (but then I'm no expert with that tool). I'm going to try and compile a debug version of gcc-4.4.3. Will make STAGE2_CFLAGS="-g -O0" STAGE3_CFLAGS="-g -O0" all make install produce the result I'm looking for?
Created attachment 20458 [details] Output of strace -F -emmap2,mremap,brk,setrlimit g++ -c -O2 bugtest.ii Of course strace is pointless if I don't follow forks. This strace output follows cc1plus as well. It still looks harmless to me though.
Comment on attachment 20443 [details] bugtest.ii to reproduce the segfault. Use a better MIME type.
Created attachment 20459 [details] Output from a gdb session on g++-4.4.3 OK, almost right. I created a debug build for gcc-4.4.3: $ g++-4.4.3 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../gcc-4.4.3/configure --prefix=/home/oberlaen/local/stow/gcc-4.4.3/ --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++ --enable-shared --disable-multiarch --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --program-suffix=-4.4.3 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-multilib --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.3 (GCC) I built with make CFLAGS="-g -O0" CXXFLAGS="-g -O0" STAGE2_CFLAGS="-g -O0" STAGE3_CFLAGS="-g -O0" I then ran g++-4.4.3 -save-temps -o bugtest.out -c -O2 bugtest.ii and extracted the cc1plus command line through strace. The attachment contains the results from a gdb run on cc1plus -fpreprocessed bugtest.ii -quiet -dumpbase bugtest.ii -mtune=generic -march=i486 -auxbase bugtest -O2 -o bugtest.s Hope this tells you something. Please tell me if I can get you any more info. Best regards, Jan
(In reply to comment #13) Oh, and another thing: at the moment of the segfault, memory usage says $ ps v -C cc1plus PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND 19072 pts/2 T 0:00 0 10015 36428 34760 0.8 <cc1plus...>
Thanks for the extra info - I can't reproduce it, but I can't test on a real 32bit host. In the absence of any suggestions from anyone else, could you try reconfiguring with --enable-checking=all instead of --enable-checking=release ? That will enable some internal consistency checks, which make the compiler slower but might reveal where it's going wrong.
This has been fixed on the 4.4 branch, I can reproduce it with 4.4.3.
(In reply to comment #16) > This has been fixed on the 4.4 branch, I can reproduce it with 4.4.3. OK, thanks for the information. I'm currently compiling gcc from the 4.4 branch in svn to verify.
(In reply to comment #17) > (In reply to comment #16) > > This has been fixed on the 4.4 branch, I can reproduce it with 4.4.3. > > OK, thanks for the information. I'm currently compiling gcc from the 4.4 > branch in svn to verify. Just tested against the current SVN gcc-4_4-branch, which works fine. Thanks for your help!