cse.c bug

cse.c bug

[Thomas Koenig]

The following, rather minimalistic program causes an assignment of
a garbage value in cse.c, caught by checkergcc, with 970924 with Haifa
on a Linux-486-libc6 system, when compiled with optimization.

$ cat hello.i
int main()
{
    return 0;
}
$ cc1 -O hello.i

[...]

From Checker (pid:17317): (rus) read uninitialized byte(s) in the stack.
When Reading 4 byte(s) at address 0xbfffb40c, inside the stack.
Stack frames are:
        pc=0x08295537 in cse_insn() at cse.c:7512
        pc=0x08299d59 in cse_basic_block() at cse.c:8431
        pc=0x082995c6 in cse_main() at cse.c:8313
        pc=0x080bb3d6 in rest_of_compilation() at ./toplev.c:3208
        pc=0x08086f62 in finish_function() at c-decl.c:7047
        pc=0x0805aa31 in yyparse() at c-parse.y:316
        pc=0x080b8329 in compile_file() at ./toplev.c:2486
        pc=0x080c035c in main() at ./toplev.c:4331
        pc=0x08058f6f in checker_text_end() at ./end.c:9

The statement in question is

  prev_insn_cc0_mode = this_insn_cc0_mode;

It appears that this_insn_cc0_mode was never assigned a value, so it
contains garbage, which probably is suboptimal.

[Did I mention that playing around with Checker is fun? :-]
-- 
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.

Re: cse.c bug

[Thomas Koenig]

I wrote:

>[Did I mention that playing around with Checker is fun? :-]

Before I get more E-Mails asking what Checker is, here is its
description from the Linux GNU/Debian package:

# Drop-in addition to `gcc' that allows programmers to find most
# memory-related bugs easily.  Checker automatically finds:
# .
#     * null pointer dereferences (read, write, and execute accesses)
#     * writes to read-only memory
#     * accesses to free blocks (read, write, and execute)
#     * reads/writes to uninitialized bytes (in automatic and dynamic memory)
#     * reads/writes to "red zones" (in automatic and dynamic memory)
#     * reads/writes/executes outside memory segments
#     * free called with address not obtained from malloc
#     * free an already freed block
#     * ...and many more!
# .
# Checker's main disadvantage is that it causes the program to run many
# times slower.  You can compile your program to use Checker by using
# the command `checkergcc' in place of `gcc'.

Checker does this by manipulating the output of the assembler.  Each
assembler instruction is replaced by a sequence of instructions which
checks all these things.  Of course, this is highly machine-dependend,
causes enormous code bloat and makes the code slooooow.

Checker so far is only available for i386-linux and sparc-linux (AFAIK).
The only version which really works is the one for Debian hamm
(unstable).  It includes glibc2.0.5 and a few other goodies, and is
based on gcc 2.7.2.3.  It has found quite a number of bugs in my
programs, and at least four bugs in glibc (or so I'm told :-).  If you
run Linux/386 with glibc 2.0.5, try to get this version from
ftp://ftp.debian.org/pub/linux/debian/hamm/hamm/binary-i386/devel/checker_0.8-18.deb
If you don't have dpkg installed, you can unpack a *.deb file it with
"ar x foo.deb ; tar -xvzf data.tar.gz"

The tests I've run on egcs were done with the first-stage compiler,
with "CC=checkergcc configure".
-- 
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.

Re: cse.c bug

[Joe Buck]

> Before I get more E-Mails asking what Checker is, here is its
> description from the Linux GNU/Debian package:

For those that have used Purify, Checker is a semi-clone.  It differs
in that Purify can work with .o files, modifying them to produce new
.o files, while Checker adds the debug code by modifying the assembler,
but other than that, their design is much the same.

[ An exact clone would infringe a patent :-( ].

Re: cse.c bug

[Jeffrey A Law]

  In message < 199709301557.QAA02401@mvmap66.ciw.uni-karlsruhe.de >you write:
  > The following, rather minimalistic program causes an assignment of
  > a garbage value in cse.c, caught by checkergcc, with 970924 with Haifa
  > on a Linux-486-libc6 system, when compiled with optimization.
Thanks.  I think I've fixed this (though the fix won't appear until
next week's snapshot).
jeff

cse.c bug

[Thomas Koenig]

The following, rather minimalistic program causes an assignment of
a garbage value in cse.c, caught by checkergcc, with 970924 with Haifa
on a Linux-486-libc6 system, when compiled with optimization.

$ cat hello.i
int main()
{
    return 0;
}
$ cc1 -O hello.i

[...]

From Checker (pid:17317): (rus) read uninitialized byte(s) in the stack.
When Reading 4 byte(s) at address 0xbfffb40c, inside the stack.
Stack frames are:
        pc=0x08295537 in cse_insn() at cse.c:7512
        pc=0x08299d59 in cse_basic_block() at cse.c:8431
        pc=0x082995c6 in cse_main() at cse.c:8313
        pc=0x080bb3d6 in rest_of_compilation() at ./toplev.c:3208
        pc=0x08086f62 in finish_function() at c-decl.c:7047
        pc=0x0805aa31 in yyparse() at c-parse.y:316
        pc=0x080b8329 in compile_file() at ./toplev.c:2486
        pc=0x080c035c in main() at ./toplev.c:4331
        pc=0x08058f6f in checker_text_end() at ./end.c:9

The statement in question is

  prev_insn_cc0_mode = this_insn_cc0_mode;

It appears that this_insn_cc0_mode was never assigned a value, so it
contains garbage, which probably is suboptimal.

[Did I mention that playing around with Checker is fun? :-]
--
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.