Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Valgrind memory access errors on trivial files #7

Open
charles-randall opened this issue Mar 17, 2021 · 1 comment
Open

Valgrind memory access errors on trivial files #7

charles-randall opened this issue Mar 17, 2021 · 1 comment

Comments

@charles-randall
Copy link
Contributor

charles-randall commented Mar 17, 2021

Sorting the attached 3-line file under valgrind gives the attached errors on my system. I don't think that there's anything special about the input file as it's trivial.

$ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

$ valgrind --version
valgrind-3.15.0

Msort compiled with "gcc -ggdb" or "gcc -g" as /tmp/msort-g,

$ valgrind --log-file=abc.valgrind.txt /tmp/msort-g abc.txt
a
b
c

This produces the correct output but please see the valgrind log.

Can you reproduce this? Is this real?

The first error is,

==3408920== Invalid read of size 4
==3408920==    at 0x4A337D7: fgets (iofgets.c:47)
==3408920==    by 0x10AB49: fillBuffer (msort.c:666)
==3408920==    by 0x10B32D: handleMerges (msort.c:846)
==3408920==    by 0x10BE19: main (msort.c:1131)
==3408920==  Address 0x4ba5b70 is 0 bytes inside a block of size 472 free'd
==3408920==    at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==3408920==    by 0x4A33042: _IO_deallocate_file (libioP.h:863)
==3408920==    by 0x4A33042: fclose@@GLIBC_2.2.5 (iofclose.c:74)
==3408920==    by 0x10B391: handleMerges (msort.c:856)
==3408920==    by 0x10BE19: main (msort.c:1131)
==3408920==  Block was alloc'd at
==3408920==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==3408920==    by 0x4A33AAD: __fopen_internal (iofopen.c:65)
==3408920==    by 0x4A33AAD: fopen@@GLIBC_2.2.5 (iofopen.c:86)
==3408920==    by 0x10B28E: handleMerges (msort.c:827)
==3408920==    by 0x10BE19: main (msort.c:1131)

abc.txt
abc.valgrind.txt

@charles-randall
Copy link
Contributor Author

I believe that you're using a filehandle after it has been closed. The easy way to find this is to set the filehandle to NULL after calling fclose() and the program will crash when you try to use a filehandle that's already been closed.

E.g., replace,
fclose(f1);

with,
fclose(f1); f1=NULL;

everywhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant