memcmp() checker: memory access errors

[kolmogolov@gmail.com]

/*
Hi, I have removed things irrelevant to reproducing the problem.
What's wrong with my code? Thanks in advance for any hint!
1166425362
*/


#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>

int probe_img(FILE *fp)
{
unsigned char *data;
unsigned char KDF_header[4]={0x01, 0x03, 0x13, 0x5E};
int probe_len = 256;
int type=-1;

data = malloc( probe_len );
assert ( NULL != data );
assert ( 1 == fread(data, probe_len, 1, fp) );

if ( !memcmp(data, KDF_header, 4) )
{
type = 3;
}

return type;
}

int main(void)
{
FILE *fp = fopen("sample.k df", "r");
assert ( NULL != fp);
printf("type=%d \n", probe_img(fp) );
return 0;
}

/*
$ echo $CHECKEROPTS
-p -v -t -o=checker.out
$ !chec
checker gcc -Wall bug.c
$ rm checker.out
$ ls -l sample.kdf
-rwxr-xr-x 1 chen mitarb 3075 Feb 10 1997 sample.kdf
$ ./a.out sample.kdf
type=3
$ cat checker.out

Checker 0.9.9.1 (i686-pc-linux-gnu) Copyright (C) 1998 Tristan Gingold.
This program has been compiled with `checkergcc' or `checkerg++'.
Checker is a memory access detector.
Checker is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
For more information, set CHECKEROPTS to `--help'

>From Checker (pid:03038): `./a.out' is running (Sun Dec 17 22:47:01

2006)

>From Checker (pid:03038): (mes) debugging message for the user.

begin end rights name path
08048000 0805b58c T- r-x .text ./a.out
0805c000 0805fdbc -D rw- .data
b7fa9000 b7fb27fc T- r-x .text /lib/libgcc_s.so.1
b7fb37fc b7fb4000 -D rw- .data /lib/libgcc_s.so.1
08048000 0805b58c T- r-x .text
0805c000 0805fdbc -D rw- .data
b7e60000 b7f875a4 T- r-x .text /lib/tls/libc.so.6
b7f8815c b7f9189c -D rw- .data /lib/tls/libc.so.6
b7fb7000 b7fcb808 T- r-x .text /lib/ld-linux.so.2
b7fccca0 b7fce000 -D rw- .data /lib/ld-linux.so.2

>From Checker (pid:03038): (mes) debugging message for the user.

Memory map:
Name | Base | End | Size | RWX | Type
---------------+------------+------------+-------------+-----+-----
NULL zone | 0x00000000 | 0x08047fff | 128 Mb | --- | Void
text segment | 0x08048000 | 0x0805b58b | 77 kb | r-x | Text
..text | 0x08048000 | 0x0805b58b | 77 kb | r-x | ROnly
(nothing) | 0x0805b58c | 0x0805bfff | 2 kb | --- | -
data segment | 0x0805c000 | 0x0805fdbb | 15 kb | rw- | RW
..data | 0x0805c000 | 0x0805fdbb | 15 kb | rw- | RW
(nothing) | 0x0805fdbc | 0xb7e5ffff | 2814 Mb | --- | -
..text | 0xb7e60000 | 0xb7f875a3 | 1181 kb | r-x | ROnly
(nothing) | 0xb7f875a4 | 0xb7f87fff | 2 kb | --- | -
..data | 0xb7f88000 | 0xb7f9189b | 38 kb | rw- | RW
(nothing) | 0xb7f9189c | 0xb7fa8fff | 93 kb | --- | -
..text | 0xb7fa9000 | 0xb7fb27fb | 37 kb | r-x | ROnly
(nothing) | 0xb7fb27fc | 0xb7fb2fff | 2 kb | --- | -
..data | 0xb7fb3000 | 0xb7fb3fff | 4 kb | rw- | RW
(nothing) | 0xb7fb4000 | 0xb7fb6fff | 12 kb | --- | -
..text | 0xb7fb7000 | 0xb7fcb807 | 82 kb | r-x | ROnly
(nothing) | 0xb7fcb808 | 0xb7fcbfff | 2040 b | --- | -
..data | 0xb7fcc000 | 0xb7fcdfff | 8 kb | rw- | RW
(nothing) | 0xb7fce000 | 0xbffcd7b3 | 127 Mb | --- | -
stack | 0xbffcd7b4 | 0xbfffffff | 202 kb | rwx | Normal
# malloc (352) = 0x8060134;
# malloc (256) = 0x80602d4;

>From Checker (pid:03038): (rus) read uninitialized byte(s) in the

stack.
When Reading 1 byte(s) at address 0xbffce798, inside the stack.
known stack limit= 0xbffce680

>From Checker (pid:03038): (mes) debugging message for the user.

08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 04 05 06 07
0xbffce798: W W W W RW RW RW RW RW RW RW RW RW RW RW RW
0xbffce7a8: RW RW RW RW W W W W RW RW RW RW RW RW RW RW
Stack frames are:
pc=0x08055bb2 in checker_text_st ubs_begin at
stubs/begin-stubs.c:7
pc=0x08048d73 in probe_img at bug.c:25
pc=0x08048fdb in main at bug.c:37
pc=0x08055d53 in checker_text_st ubs_begin at
stubs/begin-stubs.c:7
pc=0xb7e74ea8 in checker_text_st ubs_end at stubs/end-stubs.c:7
pc=0x080487e8 in *unknown* at *unknown*:0

>From Checker (pid:03038): (rus) read uninitialized byte(s) in the

stack.
When Reading 1 byte(s) at address 0xbffce799, inside the stack.
known stack limit= 0xbffce680

>From Checker (pid:03038): (mes) debugging message for the user.

08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 04 05 06 07
0xbffce798: W W W W RW RW RW RW RW RW RW RW RW RW RW RW
0xbffce7a8: RW RW RW RW W W W W RW RW RW RW RW RW RW RW
Stack frames are:
pc=0x08055bb2 in checker_text_st ubs_begin at
stubs/begin-stubs.c:7
pc=0x08048d73 in probe_img at bug.c:25
pc=0x08048fdb in main at bug.c:37
pc=0x08055d53 in checker_text_st ubs_begin at
stubs/begin-stubs.c:7
pc=0xb7e74ea8 in checker_text_st ubs_end at stubs/end-stubs.c:7
pc=0x080487e8 in *unknown* at *unknown*:0

>From Checker (pid:03038): (rus) read uninitialized byte(s) in the

stack.
When Reading 1 byte(s) at address 0xbffce79a, inside the stack.
known stack limit= 0xbffce680

>From Checker (pid:03038): (mes) debugging message for the user.

08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 04 05 06 07
0xbffce798: W W W W RW RW RW RW RW RW RW RW RW RW RW RW
0xbffce7a8: RW RW RW RW W W W W RW RW RW RW RW RW RW RW
Stack frames are:
pc=0x08055bb2 in checker_text_st ubs_begin at
stubs/begin-stubs.c:7
pc=0x08048d73 in probe_img at bug.c:25
pc=0x08048fdb in main at bug.c:37
pc=0x08055d53 in checker_text_st ubs_begin at
stubs/begin-stubs.c:7
pc=0xb7e74ea8 in checker_text_st ubs_end at stubs/end-stubs.c:7
pc=0x080487e8 in *unknown* at *unknown*:0

>From Checker (pid:03038): (rus) read uninitialized byte(s) in the

stack.
When Reading 1 byte(s) at address 0xbffce79b, inside the stack.
known stack limit= 0xbffce680

>From Checker (pid:03038): (mes) debugging message for the user.

08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 04 05 06 07
0xbffce798: W W W W RW RW RW RW RW RW RW RW RW RW RW RW
0xbffce7a8: RW RW RW RW W W W W RW RW RW RW RW RW RW RW
Stack frames are:
pc=0x08055bb2 in checker_text_st ubs_begin at
stubs/begin-stubs.c:7
pc=0x08048d73 in probe_img at bug.c:25
pc=0x08048fdb in main at bug.c:37
pc=0x08055d53 in checker_text_st ubs_begin at
stubs/begin-stubs.c:7
pc=0xb7e74ea8 in checker_text_st ubs_end at stubs/end-stubs.c:7
pc=0x080487e8 in *unknown* at *unknown*:0

>From Checker (pid:03038): (prf) profile results.

The stack was handled (accessed) 130 times.
The data segment was handled (accessed) 0 time.
The text segment was handled (accessed) 4 times.
The NULL zone was handled (accessed) 0 time.
The .text was handled (accessed) 0 time.
The .data was handled (accessed) 0 time.
The .text was handled (accessed) 0 time.
The .data was handled (accessed) 0 time.
The .text was handled (accessed) 0 time.
The .data was handled (accessed) 0 time.
The .text was handled (accessed) 0 time.
The .data was handled (accessed) 0 time.
The heap (sbrk) was handled (accessed) 10 times.
The program accessed memory 144 times.
The stack limit was adjusted 47 times.
4 memory access errors reported.
4 memory access errors.
2 malloc/mmalloc calls.
0 free/mfree calls.
0 realloc/mrealloc calls.
Total time used for garbage detecting: 0 sec(s) 0 usecs.

*/

[Richard Bos]

Re: memcmp() checker: memory access errors

"kolmogolov@gma il.com" <kolmogolov@gma il.comwrote:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
>
int probe_img(FILE *fp)
{
unsigned char *data;
unsigned char KDF_header[4]={0x01, 0x03, 0x13, 0x5E};
int probe_len = 256;
int type=-1;
>
data = malloc( probe_len );
assert ( NULL != data );

I seriously hope that this kind of error handling is not going into any
of your production code. It is not nice to your users.

assert ( 1 == fread(data, probe_len, 1, fp) );

I _very_ seriously hope that this kind of code is not going into any of
your production _or_ testing code. It is impossible to maintain _and_
nasty on your users.

if ( !memcmp(data, KDF_header, 4) )
{
type = 3;
}
>
return type;
}
>
int main(void)
{
FILE *fp = fopen("sample.k df", "r");
assert ( NULL != fp);
printf("type=%d \n", probe_img(fp) );
return 0;
}

From Checker (pid:03038): (rus) read uninitialized byte(s) in the

stack.

pc=0x08048d73 in probe_img at bug.c:25

I'm no expert on Checker, but AFAICT, and if I counted correctly, it
seems to think that your memcmp() call accesses an uninitialised
automatic variable. If so, it's wrong. There's nothing wrong with that
code that I can find, except as I indicated above. These errors _might_
cause an uninitialised pointer to be read, but only if you #define
NDEBUG. And if you do that, with the above broken assert()s, you break a
whole bit more than that - your file doesn't get read at all.

That _might_ be it, but it would be a weird thing to do; you'd have to
have NDEBUG defined by your make script or something similar. The code
as you posted it doesn't #define it.
Anyway, it's easy to check. Remove all assert()s and replace them by
some saner error handling. assert() is for programmer error (forgot a
case), not for user error (file not found) or system limitations (out of
memory). Having done that, run it through Checker again. If that solves
the problem, you know what to avoid in the future, and you also know
that something is automatically defining NDEBUG for you - something to
avoid while still debugging.

Richard

[malc]

Re: memcmp() checker: memory access errors

"kolmogolov@gma il.com" <kolmogolov@gma il.comwrites:

[..snip..]

int probe_img(FILE *fp)
{
unsigned char *data;
unsigned char KDF_header[4]={0x01, 0x03, 0x13, 0x5E};
int probe_len = 256;
int type=-1;
>
data = malloc( probe_len );
assert ( NULL != data );
assert ( 1 == fread(data, probe_len, 1, fp) );
>
if ( !memcmp(data, KDF_header, 4) )
{
type = 3;
}
>
return type;
}

There's a memory leak here. But as far as i can see that's not what
checker complains about.

[..snip..]

P.S. Dangerous usage of `assert' is addressed in the reply by Richard Bos.
And excessive reading of 256 bytes where you really need 4 should be
self evident.

--
vale

[Richard Bos]

Re: memcmp() checker: memory access errors

malc <malc@pulsesoft .comwrote:

"kolmogolov@gma il.com" <kolmogolov@gma il.comwrites:
>
[..snip..]
>

int probe_img(FILE *fp)
{
unsigned char *data;
unsigned char KDF_header[4]={0x01, 0x03, 0x13, 0x5E};
int probe_len = 256;
int type=-1;

data = malloc( probe_len );
assert ( NULL != data );
assert ( 1 == fread(data, probe_len, 1, fp) );

if ( !memcmp(data, KDF_header, 4) )
{
type = 3;
}

return type;
}

>
There's a memory leak here. But as far as i can see that's not what
checker complains about.

Doesn't even get there. I'm beginning to suspect that what Checker
checked is not the posted code.

And excessive reading of 256 bytes where you really need 4 should be
self evident.

Not necessarily; if the rest of the header is needed by the rest of the
function, which just happens not to be written yet, it may be the right
size to read for the (as yet to be) completed code.

Richard

[kolmogolov@gmail.com]

Re: memcmp() checker: memory access errors


Richard Bos wrote:

malc <malc@pulsesoft .comwrote:
>

(...)

There's a memory leak here. But as far as i can see that's not what
checker complains about.

>
Doesn't even get there. I'm beginning to suspect that what Checker
checked is not the posted code.

I almost suspected that too after reading your words and went back;
booted a machine freshly; cd /tmp; extract only the file "bug.c" (which
is
extactly the same file posted for I have just cut and pasted the posted
codes and did a diff to bug.c); checker gcc -Wall bug.c;
../a.out sample.kdf and there it is:

(...)
4 memory access errors reported.
4 memory access errors.
2 malloc/mmalloc calls.
0 free/mfree calls.
0 realloc/mrealloc calls.
Total time used for garbage detecting: 0 sec(s) 0 usecs.

The file "bug.c" has been extracted from a much bigger
progam "any2pgm.c" for the posting, including replacing
error handling by assert()'s to make it small and ready to
compile. Would anyone please bounds-check that for me
too using her/his checker?

And by memory leak, you do mean the malloc'ed array
data[]? If so, thanks for the hint. It is called in the
whole program only once but I'll keep an eye on that.
If not, would you please verbose on this for I'm no
professional programmer.

BTW. I do ungetc() all 256 bytes in data[] back to the stream
for decoupling the probe_img() from all the other functions
for parsing the details of the headers. I thought tha it were s
a proper size for probing many kinds of my image files.

I'll re-read about the mentioned NDEBUG again for I
don't get it yet ...

[malc]

Re: memcmp() checker: memory access errors

"kolmogolov@gma il.com" <kolmogolov@gma il.comwrites:

Richard Bos wrote:

>malc <malc@pulsesoft .comwrote:
>>

(...)

There's a memory leak here. But as far as i can see that's not what
checker complains about.

[..snip..]

The file "bug.c" has been extracted from a much bigger
progam "any2pgm.c" for the posting, including replacing
error handling by assert()'s to make it small and ready to
compile. Would anyone please bounds-check that for me
too using her/his checker?

valgrind(http://valgrind.org) does not report any errors w.r.t. memeory
accesses.

And by memory leak, you do mean the malloc'ed array
data[]? If so, thanks for the hint. It is called in the
whole program only once but I'll keep an eye on that.
If not, would you please verbose on this for I'm no
professional programmer.

Yes, the code allocates 256 bytes of (temporary)stor age that is never
freed.

BTW. I do ungetc() all 256 bytes in data[] back to the stream
for decoupling the probe_img() from all the other functions
for parsing the details of the headers. I thought tha it were s
a proper size for probing many kinds of my image files.

I doubt that calling a function that can fail 256 times is a good
practice, especially in this context.

I'll re-read about the mentioned NDEBUG again for I
don't get it yet ...

NDEBUG will turn make a noop out of assert, so all the checks bug.c
does will be lost.

--
vale

[Random832]

Re: memcmp() checker: memory access errors

2006-12-18 <m21wmx9dsi.fsf @pulsesoft.com> ,
malc wrote:

"kolmogolov@gma il.com" <kolmogolov@gma il.comwrites:

>I'll re-read about the mentioned NDEBUG again for I
>don't get it yet ...

>
NDEBUG will turn make a noop out of assert, so all the checks bug.c
does will be lost.

As will the code inside these checks. It's never good to have an
assert() with side effects.

I think the problem is he is missing the point of assert() entirely.

[Kohn Emil Dan]

Re: memcmp() checker: memory access errors



On Mon, 18 Dec 2006, kolmogolov@gmai l.com wrote:

<snipped>

>
BTW. I do ungetc() all 256 bytes in data[] back to the stream
for decoupling the probe_img() from all the other functions
for parsing the details of the headers. I thought tha it were s
a proper size for probing many kinds of my image files.
>

Be careful, because ungetc() can fail to push back the bytes to the input
stream. The standard guarantees that only one push back can succeed
without an intervening read or file positioning function (in which case
your pushed back characters will be be discarded).

Emil

[kolmogolov@gmail.com]

Re: memcmp() checker: memory access errors


Kohn Emil Dan wrote:

On Mon, 18 Dec 2006, kolmogolov@gmai l.com wrote:
>
<snipped>

BTW. I do ungetc() all 256 bytes in data[] back to the stream
for decoupling the probe_img() from all the other functions
for parsing the details of the headers. I thought tha it were s
a proper size for probing many kinds of my image files.

>
>
Be careful, because ungetc() can fail to push back the bytes to the input
stream. The standard guarantees that only one push back can succeed
without an intervening read or file positioning function (in which case
your pushed back characters will be be discarded).

So, for safety I'll have to either maintain a 256-byte global buffer
or to minimize the size of it whenever possible if I insist on not
calling
fseek() for the sake of being able to read from a pipe (which is off
topic).

I have also installed the memory debugger valgrin mentioned by malc.
Thanks too. This is really handy for checking at runtime and it did
report
my 256-byte memory leak although it did not report any other error.
So, I'll be serious about the free() which is left out also in the
actual
function. And I see that this is no good practice at all. The same to
assert() and NDEBUG. I have reread the manpage, removed all asserts,
and have gotten the same result from the Checker. It reported 4 memory
access errors supposedly at memcmp as Richard has noted. But the
Checker does not report the source-line every time. I have not
strip'ped
the symbols from the binary though.

Even after I changed

if ( 1 != fread(data, probe_len, 1, fp) ) return -2;

explicitly to

n_items_read = fread(data, probe_len, 1, fp);
if ( 1 != n_items_read ) return -2;

I got the same result of reading 4 uninitialized bytes in the stack
at the line

if ( !memcmp(data, KDF_header, 4) )

I thought this could have been the data[0] to data[3] because
KDF_header[] has been unconditonally declared and initialized.

What next? Do you think I should send in a bug-report to the author
of my Checker?

[Arthur J. O'Dwyer]

Re: memcmp() checker: memory access errors


On Mon, 17 Dec 2006, kolmogolov@gmai l.com wrote:

>
/*
Hi, I have removed things irrelevant to reproducing the problem.
What's wrong with my code? Thanks in advance for any hint!
1166425362
*/

I see four bugs, two of which /might/ cause your problem.
First, you malloc 'data' and never free it; second, and more importantly,
you try to 'fread' out of a file that was opened as text, not binary.
To fix the second bug, use "rb" instead of "r" as the second argument
to 'fopen'. Does the problem go away?

Any time you're dealing with bits and bytes, you should be using
files opened in binary mode, not text mode.

Third, the line

assert ( 1 == fread(data, probe_len, 1, fp) );

should probably be changed stylistically to

assert ( probe_len == fread(data, 1, probe_len, fp) );

and /definitely/ needs to be changed to

rc = fread(data, 1, probe_len, fp);
assert(rc == probe_len);

so that it will continue to work when NDEBUG is #defined (e.g., when
you release the product). This is probably the big bug.

Never put anything inside 'assert' that you want to be evaluated.
The same goes for any in-house assertion-checking macros or functions;
it'll make life easier for the programmers who come after you.

-Arthur

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
>
int probe_img(FILE *fp)
{
unsigned char *data;
unsigned char KDF_header[4]={0x01, 0x03, 0x13, 0x5E};
int probe_len = 256;
int type=-1;
>
data = malloc( probe_len );
assert ( NULL != data );
assert ( 1 == fread(data, probe_len, 1, fp) );
>
if ( !memcmp(data, KDF_header, 4) )
{
type = 3;
}
>
return type;
}
>
int main(void)
{
FILE *fp = fopen("sample.k df", "r");
assert ( NULL != fp);
printf("type=%d \n", probe_img(fp) );
return 0;
}
>
/*
$ echo $CHECKEROPTS

[big snip]

[kolmogolov@gmail.com]

Re: memcmp() checker: memory access errors


Arthur J. O'Dwyer wrote:

[snip]

obe_len == fread(data, 1, probe_len, fp) );

>
and /definitely/ needs to be changed to
>
rc = fread(data, 1, probe_len, fp);
assert(rc == probe_len);
>
so that it will continue to work when NDEBUG is #defined (e.g., when
you release the product). This is probably the big bug.
>
Never put anything inside 'assert' that you want to be evaluated.
The same goes for any in-house assertion-checking macros or functions;
it'll make life easier for the programmers who come after you.
>

Thanks for the advice. I'll keep it in mind. However, making
all the above changes did not suppress the Checker output

(...)
4 memory access errors reported.
4 memory access errors.

regards.

[Richard Bos]

Re: memcmp() checker: memory access errors

"kolmogolov@gma il.com" <kolmogolov@gma il.comwrote:

Arthur J. O'Dwyer wrote:
>

and /definitely/ needs to be changed to

rc = fread(data, 1, probe_len, fp);
assert(rc == probe_len);

so that it will continue to work when NDEBUG is #defined (e.g., when
you release the product). This is probably the big bug.

Never put anything inside 'assert' that you want to be evaluated.
The same goes for any in-house assertion-checking macros or functions;
it'll make life easier for the programmers who come after you.

>
Thanks for the advice. I'll keep it in mind. However, making
all the above changes did not suppress the Checker output
>
(...)
4 memory access errors reported.
4 memory access errors.

Try this code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int probe_img(FILE *fp)
{
unsigned char *data;
unsigned char KDF_header[4]={0x01, 0x03, 0x13, 0x5E};
int probe_len=256;
int type=-1;

data=malloc(pro be_len);
if (!data) {
fputs("Out of memory in probe_img().\n" , stderr);
return -2;
}
if (fread(data, probe_len, 1, fp)!=1) {
fputs("Image file too small in probe_img().\n" , stderr);
return -2;
}

if (!memcmp(data, KDF_header, 4))
type=3;

free(data);
return type;
}

int main(void)
{
FILE *fp;

if (!(fp=fopen("sa mple.kdf", "r"))) {
fputs("File not found or not readable.\n", stderr);
return EXIT_FAILURE;
}

printf("type=%d \n", probe_img(fp) );

return 0;
}

If that still gives error messages, Checker is buggy.

Richard

[kolmogolov@gmail.com]

Re: memcmp() checker: memory access errors


Richard Bos wrote:

>
Try this code:
>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
>
int probe_img(FILE *fp)
{
unsigned char *data;
unsigned char KDF_header[4]={0x01, 0x03, 0x13, 0x5E};
int probe_len=256;
int type=-1;
>
data=malloc(pro be_len);
if (!data) {
fputs("Out of memory in probe_img().\n" , stderr);
return -2;
}
if (fread(data, probe_len, 1, fp)!=1) {
fputs("Image file too small in probe_img().\n" , stderr);
return -2;
}
>
if (!memcmp(data, KDF_header, 4))
type=3;
>
free(data);
return type;
}
>
int main(void)
{
FILE *fp;
>
if (!(fp=fopen("sa mple.kdf", "r"))) {
fputs("File not found or not readable.\n", stderr);
return EXIT_FAILURE;
}
>
printf("type=%d \n", probe_img(fp) );
>
return 0;
}
>
If that still gives error messages, Checker is buggy.
>

Ok, thanks a lot, Richard. Then the Checker is buggy.

Checker 0.9.9.1 (i686-pc-linux-gnu) Copyright (C) 1998 Tristan Gingold.
This program has been compiled with `checkergcc' or `checkerg++'.
Checker is a memory access detector.
Checker is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
For more information, set CHECKEROPTS to `--help'

>From Checker (pid:06761): `./a.out' is running (Fri Dec 22 21:26:10

2006)

>From Checker (pid:06761): (mes) debugging message for the user.

begin end rights name path
08048000 0805b64c T- r-x .text ./a.out
0805c000 0805fddc -D rw- .data
b7f21000 b7f2a7fc T- r-x .text /lib/libgcc_s.so.1
b7f2b7fc b7f2c000 -D rw- .data /lib/libgcc_s.so.1
08048000 0805b64c T- r-x .text
0805c000 0805fddc -D rw- .data
b7dd8000 b7eff5a4 T- r-x .text /lib/tls/libc.so.6
b7f0015c b7f0989c -D rw- .data /lib/tls/libc.so.6
b7f2f000 b7f43808 T- r-x .text /lib/ld-linux.so.2
b7f44ca0 b7f46000 -D rw- .data /lib/ld-linux.so.2

>From Checker (pid:06761): (mes) debugging message for the user.

Memory map:
Name | Base | End | Size | RWX | Type
---------------+------------+------------+-------------+-----+-----
NULL zone | 0x00000000 | 0x08047fff | 128 Mb | --- | Void
text segment | 0x08048000 | 0x0805b64b | 77 kb | r-x | Text
..text | 0x08048000 | 0x0805b64b | 77 kb | r-x | ROnly
(nothing) | 0x0805b64c | 0x0805bfff | 2 kb | --- | -
data segment | 0x0805c000 | 0x0805fddb | 15 kb | rw- | RW
..data | 0x0805c000 | 0x0805fddb | 15 kb | rw- | RW
(nothing) | 0x0805fddc | 0xb7dd7fff | 2813 Mb | --- | -
..text | 0xb7dd8000 | 0xb7eff5a3 | 1181 kb | r-x | ROnly
(nothing) | 0xb7eff5a4 | 0xb7efffff | 2 kb | --- | -
..data | 0xb7f00000 | 0xb7f0989b | 38 kb | rw- | RW
(nothing) | 0xb7f0989c | 0xb7f20fff | 93 kb | --- | -
..text | 0xb7f21000 | 0xb7f2a7fb | 37 kb | r-x | ROnly
(nothing) | 0xb7f2a7fc | 0xb7f2afff | 2 kb | --- | -
..data | 0xb7f2b000 | 0xb7f2bfff | 4 kb | rw- | RW
(nothing) | 0xb7f2c000 | 0xb7f2efff | 12 kb | --- | -
..text | 0xb7f2f000 | 0xb7f43807 | 82 kb | r-x | ROnly
(nothing) | 0xb7f43808 | 0xb7f43fff | 2040 b | --- | -
..data | 0xb7f44000 | 0xb7f45fff | 8 kb | rw- | RW
(nothing) | 0xb7f46000 | 0xbfb66b63 | 124 Mb | --- | -
stack | 0xbfb66b64 | 0xbfffffff | 4 Mb | rwx | Normal
# malloc (352) = 0x8060134;
# malloc (256) = 0x80602d4;

>From Checker (pid:06761): (rus) read uninitialized byte(s) in the

stack.
When Reading 1 byte(s) at address 0xbfb67b48, inside the stack.
known stack limit= 0xbfb67a30

>From Checker (pid:06761): (mes) debugging message for the user.

08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 04 05 06 07
0xbfb67b48: W W W W RW RW RW RW RW RW RW RW RW RW RW RW
0xbfb67b58: RW RW RW RW W W W W RW RW RW RW RW RW RW RW
Stack frames are:

>From Checker (pid:06761): (rus) read uninitialized byte(s) in the

stack.
When Reading 1 byte(s) at address 0xbfb67b49, inside the stack.
known stack limit= 0xbfb67a30

>From Checker (pid:06761): (mes) debugging message for the user.

08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 04 05 06 07
0xbfb67b48: W W W W RW RW RW RW RW RW RW RW RW RW RW RW
0xbfb67b58: RW RW RW RW W W W W RW RW RW RW RW RW RW RW
Stack frames are:

>From Checker (pid:06761): (rus) read uninitialized byte(s) in the

stack.
When Reading 1 byte(s) at address 0xbfb67b4a, inside the stack.
known stack limit= 0xbfb67a30

>From Checker (pid:06761): (mes) debugging message for the user.

08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 04 05 06 07
0xbfb67b48: W W W W RW RW RW RW RW RW RW RW RW RW RW RW
0xbfb67b58: RW RW RW RW W W W W RW RW RW RW RW RW RW RW
Stack frames are:

>From Checker (pid:06761): (rus) read uninitialized byte(s) in the

stack.
When Reading 1 byte(s) at address 0xbfb67b4b, inside the stack.
known stack limit= 0xbfb67a30

>From Checker (pid:06761): (mes) debugging message for the user.

08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 04 05 06 07
0xbfb67b48: W W W W RW RW RW RW RW RW RW RW RW RW RW RW
0xbfb67b58: RW RW RW RW W W W W RW RW RW RW RW RW RW RW
Stack frames are:
# free (0x80602d4);

>From Checker (pid:06761): (prf) profile results.

The stack was handled (accessed) 131 times.
The data segment was handled (accessed) 0 time.
The text segment was handled (accessed) 4 times.
The NULL zone was handled (accessed) 0 time.
The .text was handled (accessed) 0 time.
The .data was handled (accessed) 0 time.
The .text was handled (accessed) 0 time.
The .data was handled (accessed) 0 time.
The .text was handled (accessed) 0 time.
The .data was handled (accessed) 0 time.
The .text was handled (accessed) 0 time.
The .data was handled (accessed) 0 time.
The heap (sbrk) was handled (accessed) 11 times.
The program accessed memory 146 times.
The stack limit was adjusted 48 times.
4 memory access errors reported.
4 memory access errors.
2 malloc/mmalloc calls.
1 free/mfree calls.
0 realloc/mrealloc calls.
Total time used for garbage detecting: 0 sec(s) 0 usecs.

[Ben Pfaff]

Re: memcmp() checker: memory access errors

"kolmogolov@gma il.com" <kolmogolov@gma il.comwrites:

Ok, thanks a lot, Richard. Then the Checker is buggy.
>
Checker 0.9.9.1 (i686-pc-linux-gnu) Copyright (C) 1998 Tristan Gingold.

Of course it's buggy. It's so old that it's not just
unmaintained, it's actually been retired by the FSF. See its
home page at http://www.gnu.org/software/checker/ for details.
(As a former co-maintainer, I should know.)

Use valgrind instead. It's actively maintained and easier to use
to boot.
--
"Programmer s have the right to be ignorant of many details of your code
and still make reasonable changes."
--Kernighan and Plauger, _Software Tools_