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

["Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>]

On Mon, Jul 18, 2011 at 7:21 AM, Nelson A. de Oliveira <naoliv@gmail.com> wrote:
>
> I was testing csmith (b8d96d3) with compiler_test this weekend and
> found 3 crashs with gcc (Debian's 4.6.1-1).
> I cannot reproduce any kind of crash with two of them so I am
> attaching only one that I can't test (testing with gcc -O1 or higher
> eats all my machine memory).
>
> Also I found a lot of csmith_bug* files; the code is the same for all
> despite being generated by 18 different seeds (1647861003 1800805587
> 1893949379 2033247883 2125392491 2242411515 2358272475 2497247411
> 2600809923 2706144891 2821694907 2937775475 3056492259 3172076476
> 3319675292 3510861076 4284760960 4290416599).
> Is the problem in this generated code (csmith_bug_1.c) already known?

(attached "csmith_bug_1.c" containing only "static long __undefined")

I tried the command line referenced by the block comment at the top of
"csmith_bug_1.c", which was this command line:
csmith --bitfields --packed-struct -s 4284760960

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.

John, etc.: I suggest that csmith not print *any* output until it's
ready to print *all* its output. That way, if it's killed by ulimit,
it won't leave a partial file behind.  Alternatively, I don't know if
this is possible, but depending on how considerate ulimit is, maybe
csmith should catch SIGKILL (or whatever the signal sent by ulimit is)
and print a nice unambiguous "I am slain!" message into the output
file before dying. If it had done that, then Nelson probably wouldn't
have been so confused.


> 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").

HTH,
-Arthur