[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [csmith-dev] gcc crash and csmith bug



Hi!

On Mon, Jul 18, 2011 at 4:45 PM, Arthur O'Dwyer
<arthur.j.odwyer@gmail.com> wrote:
> I noticed that csmith took about 1 second between printing the
> top-of-file boilerplate and printing the rest of the file, probably
> because it took a while to generate the rest of the file.  I suspect
> that you're using a harness script that puts an arbitrary ulimit on
> the amount of time and/or memory that csmith can use to generate the
> file, and ulimit is killing csmith when it reaches that limit. Try
> raising or getting rid of that limit, and see if the problem goes
> away.

Hmm... indeed.
I was using compiler_test.pl (distributed together with csmith); the
timeout that it's using should be increased then.

>> Also, can somebody confirm this crash (crash1.c) with gcc?
>
> No, "gcc crash1.c" works fine for me with GCC 4.7.0. When reporting a
> GCC bug, you need to provide not only the input file (crash1.c) but
> also the exact command line that you used (e.g., "gcc -O1 -w -c
> crash1.c") and also the exact version of GCC that you used (e.g., the
> output of "gcc -v").

/usr/lib/gcc-snapshot/bin/gcc -I/tmp/csmith-0.0/runtime -O1 crash1.c

With a newer version now:

$ /usr/lib/gcc-snapshot/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
20110709-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,fortran,objc,obj-c++,go
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --disable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.7-snap/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.7-snap
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.7-snap
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --disable-werror
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.0 20110709 (experimental) [trunk revision 176106]
(Debian 20110709-1)

I still can't test this one since it uses all my RAM (4GB) and makes
the machine unusable.
C programs that require a lot of memory to compile are considered OK then?

Thank you!

Best regards,
Nelson