--- Comment #18 from oberlaender at fzi dot de 2010-04-23 14:52 ---
(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 s
--- Comment #17 from oberlaender at fzi dot de 2010-04-22 15:48 ---
(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.
--
http://gcc.gnu
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-04-22 11:25
---
This has been fixed on the 4.4 branch, I can reproduce it with 4.4.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from redi at gcc dot gnu dot org 2010-04-22 10:50 ---
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-c
--- Comment #14 from oberlaender at fzi dot de 2010-04-22 09:19 ---
(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/2T 0:00 0 100
--- Comment #13 from oberlaender at fzi dot de 2010-04-22 09:13 ---
Created an attachment (id=20459)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20459&action=view)
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
Us
--- Comment #12 from oberlaender at fzi dot de 2010-04-22 08:31 ---
(From update of attachment 20443)
Use a better MIME type.
--
oberlaender at fzi dot de changed:
What|Removed |Added
--- Comment #11 from oberlaender at fzi dot de 2010-04-22 07:59 ---
Created an attachment (id=20458)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20458&action=view)
Output of strace -F -emmap2,mremap,brk,setrlimit g++ -c -O2 bugtest.ii
Of course strace is pointless if I don't fol
--- Comment #10 from oberlaender at fzi dot de 2010-04-22 07:47 ---
(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 repo
--- Comment #9 from redi at gcc dot gnu dot org 2010-04-21 16:24 ---
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
--- Comment #8 from oberlaender at fzi dot de 2010-04-21 13:42 ---
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-li
--- Comment #7 from oberlaender at fzi dot de 2010-04-21 12:40 ---
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/s
--- Comment #6 from oberlaender at fzi dot de 2010-04-21 11:48 ---
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&,
--- Comment #5 from oberlaender at fzi dot de 2010-04-20 16:51 ---
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
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-20 16:27 ---
works for me with 4.4.2 and higher - could you be running out of memory?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
--- Comment #3 from oberlaender at fzi dot de 2010-04-20 15:29 ---
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='Ubun
--- Comment #2 from oberlaender at fzi dot de 2010-04-20 14:14 ---
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
--- Comment #1 from oberlaender at fzi dot de 2010-04-20 14:08 ---
Created an attachment (id=20443)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20443&action=view)
bugtest.ii to reproduce the segfault.
This is the preprocessed source file leading to the segfault, created using g+
18 matches
Mail list logo