https://bugs.kde.org/show_bug.cgi?id=392855
--- Comment #9 from David Rankin <drankina...@suddenlinkmail.com> --- Phillip, after further discussion on StackOverflow about this bug and the problems with valgrind improperly reporting more memory allocated than the user allocated in his code, this is the best rundown I can give you: For all time, on Linux/gcc, valgrind accurately reported the number of bytes allocated by the user and provided proper exclusion files to mask any additional system memory allocated by the system not explicitly allocated in a call to `malloc, calloc or realloc` by the user. It properly showed this behavior on Archlinux, openSuSE, Ubuntu, Debian, Slack and any other distribution I ever ran valgrind on up through the 3.12 release. Beginning with the 3.13 release, the system allocated memory (not required by the user) was no longer properly excluded in the memory reported in-use by valgrind. This dramatically decreased the usefulness of valgrind as a tool for new users as the questions always surfaced, "What is this additional memory I didn't allocate", e.g. https://stackoverflow.com/questions/53026992/extra-allocs-valgrind?noredirect=1#comment92967899_53026992 All versions up through 3.12, for example reported the following for a simple example: #include <stdio.h> #include <stdlib.h> int main (void) { int *a = malloc (sizeof *a); *a = 5; printf ("a: %d\n", *a); free (a); } Compile: gcc -Wall -Wextra -pedantic -Wshadow -std=gnu11 -Ofast -o /tmp/bin/vgtest2 vgtest2.c Version Info (openSuSE Leap 42.3) gcc --version gcc (SUSE Linux) 4.8.5 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Valgrind Output: valgrind ./bin/vgtest2 ==6686== Memcheck, a memory error detector ==6686== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==6686== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==6686== Command: ./bin/vgtest2 ==6686== a: 5 ==6686== ==6686== HEAP SUMMARY: ==6686== in use at exit: 0 bytes in 0 blocks ==6686== total heap usage: 1 allocs, 1 frees, 4 bytes allocated ==6686== ==6686== All heap blocks were freed -- no leaks are possible ==6686== ==6686== For counts of detected and suppressed errors, rerun with: -v ==6686== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Perfect, 4-bytes request, 4-bytes allocated, 4-bytes reported by valgrind. Now let's look at openSuSE Leap 15 which updated to valgrind 3.13, with gcc --version gcc (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812] Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (using the same source file compiled with the same options) valgrind ./bin/vgtest2 ==9642== Memcheck, a memory error detector ==9642== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==9642== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==9642== Command: ./bin/vgtest2 ==9642== a: 5 ==9642== ==9642== HEAP SUMMARY: ==9642== in use at exit: 0 bytes in 0 blocks ==9642== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==9642== ==9642== All heap blocks were freed -- no leaks are possible ==9642== ==9642== For counts of detected and suppressed errors, rerun with: -v ==9642== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) That's not right. The user only allocated 4-bytes of memory, not 1024-bytes. Whatever exclusion files used to correctly mask the 1020-bytes not requested by the user are no longer doing their job. And Note: this is a very rudimentary example, when checking allocations on a normal sized example program, it's not uncommon to have 10,000 additional bytes reported as allocated when the user may have only required 300-bytes. Not let's turn to ArchLinux with valgrind version 3.14, the exact same problem of excess memory reporting by valgrind continues, e.g. gcc --version gcc (GCC) 8.2.1 20180831 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (same code same compiler options) valgrind ./bin/vgtest2 ==23174== Memcheck, a memory error detector ==23174== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==23174== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==23174== Command: ./bin/vgtest2 ==23174== a: 5 ==23174== ==23174== HEAP SUMMARY: ==23174== in use at exit: 0 bytes in 0 blocks ==23174== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==23174== ==23174== All heap blocks were freed -- no leaks are possible ==23174== ==23174== For counts of detected and suppressed errors, rerun with: -v ==23174== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Again the reported memory is not the 4-bytes allocated in the program, but an additional 1020-bytes the user did not allocated. And now we are seeing this problem manifest itself on programming site with "Where are the extra allocations coming from?" (see prior link above) It all boils down to either: ==6686== total heap usage: 1 allocs, 1 frees, 4 bytes allocated The correct memory reporting for the code shown has always been shown as this up until 3.13. Beginning with 3.13, valgrind begin reporting far more memory than the user requested, e.g. ==23174== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated The prior behavior is the desired and expected behavior for valgrind. That was the whole purpose behind the exclusion files -- show the user what memory he (or she) allocated and whether or not that memory was freed or still reachable. In its current state 3.13 and 3.14 provide no correlation between the bytes allocated by the user and the bytes reported as in use. I don't know how much more clear that can be made. Above are 3 examples, where 3.12 provides accurate accounting for the users allocation, and beginning 3.13 valgrind no longer accurately accounts for the memory allocated by the user. That's the bug. -- You are receiving this mail because: You are watching all bug changes.
