FS#49681 - [valgrind] shows 1024 bytes & 1 more allocation than actual
Attached to Project:
Arch Linux
Opened by David C. Rankin (drankinatty) - Sunday, 12 June 2016, 02:56 GMT
Last edited by Levente Polyak (anthraxx) - Thursday, 21 January 2021, 01:30 GMT
Opened by David C. Rankin (drankinatty) - Sunday, 12 June 2016, 02:56 GMT
Last edited by Levente Polyak (anthraxx) - Thursday, 21 January 2021, 01:30 GMT
|
Details
Description:
valgrind is reporting 1024 bytes more than actually allocated and 1 more allocation and free than preformed. Additional info: * package version(s) valgrind 3.11.0-3 Steps to reproduce: compile/run the following simple source: #include <stdio.h> #include <stdlib.h> #include <string.h> int main (int argc, char **argv) { char *d, *p = argc > 1 ? argv[1] : "my dog has fleas."; size_t len = strlen (p); if (!(d = malloc (len + 1))) { fprintf (stderr, "error: virtual memory exhausted.\n"); return 1; } printf ("\n bytes allocated : %zu\n %s\n", len + 1, strcpy (d, p)); free (d); return 0; } valgrind reports: bytes allocated : 18 my dog has fleas. ==1908== ==1908== HEAP SUMMARY: ==1908== in use at exit: 0 bytes in 0 blocks ==1908== total heap usage: 2 allocs, 2 frees, 1,042 bytes allocated ==1908== ==1908== All heap blocks were freed -- no leaks are possible valgrind should report: ==1955== HEAP SUMMARY: ==1955== in use at exit: 0 bytes in 0 blocks ==1955== total heap usage: 1 allocs, 1 frees, 18 bytes allocated ==1955== ==1955== All heap blocks were freed -- no leaks are possible It appears there is some default exclusion file that is not being applied. I don't know when this began, but I fired up an old arch install, and the problem is not present. It doesn't look like anything is missing from the PKGBUILD, is there a release note that needs patching for? |
This task depends upon
Closed by Levente Polyak (anthraxx)
Thursday, 21 January 2021, 01:30 GMT
Reason for closing: Upstream
Thursday, 21 January 2021, 01:30 GMT
Reason for closing: Upstream
#include <stdio.h>
#include <stdlib.h>
int main (void) {
int *a = malloc (sizeof *a);
*a = 5;
printf ("a: %d\n", *a);
free (a);
}
above there is a single allocation of 4-bytes, and valgrind has always (aside from the first instance of this bug) reported the 4-bytes correctly. Now it is broken again, e.g. from the current gcc and valgrind packages, you get:
$ valgrind ./bin/vgtest2
==15222== Memcheck, a memory error detector
==15222== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==15222== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==15222== Command: ./bin/vgtest2
==15222==
a: 5
==15222==
==15222== HEAP SUMMARY:
==15222== in use at exit: 0 bytes in 0 blocks
==15222== total heap usage: 2 allocs, 2 frees, 1,028 bytes allocated
==15222==
==15222== All heap blocks were freed -- no leaks are possible
==15222==
==15222== For counts of detected and suppressed errors, rerun with: -v
==15222== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
That same 1024 bytes that should be masked by a proper exclusion is back again. (the problem is much worse with when multiple allocations are made)
Apparently there has been some attempt to fix this, most likely in an upstream change (whether intentional or not), but alas, it is still FUBAR. It now reports 1-allocation of 1024-bytes, e.g.
valgrind ./bin/vgtest2
==15274== Memcheck, a memory error detector
==15274== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==15274== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==15274== Command: ./bin/vgtest2
==15274==
a: 5
==15274==
==15274== HEAP SUMMARY:
==15274== in use at exit: 0 bytes in 0 blocks
==15274== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==15274==
==15274== All heap blocks were freed -- no leaks are possible
==15274==
==15274== For counts of detected and suppressed errors, rerun with: -v
==15274== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
probably in the gcc-libs (7.3.1+20180312-1 -> 7.3.1+20180312-2) update.