| Summary: | reports false positive leaks for C++ STL or string class objects | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Björn 'besser82' Esser <besser82> | ||||
| Component: | valgrind | Assignee: | Mark Wielaard <mjw> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | dodji, jakub, jwakely, mjw, mjw | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | valgrind-3.11.0-18.fc23 valgrind-3.11.0-18.fc24 valgrind-3.11.0-19.fc24 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-04-08 17:01:54 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
Thanks. This might be a good temporary fix for the issue. Longer term I think we want valgrind and libstdc++ to coordinate more about these memory pools and cleanup at process exit. There are already some proposed patches for that: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945 https://bugs.kde.org/show_bug.cgi?id=345307 valgrind-3.11.0-18.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ba7dc44867 valgrind-3.11.0-18.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-0186345d7f valgrind-3.11.0-18.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ba7dc44867 valgrind-3.11.0-18.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-0186345d7f valgrind-3.11.0-18.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. valgrind-3.11.0-18.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. valgrind-3.11.0-19.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f04546964 valgrind-3.11.0-19.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f04546964 valgrind-3.11.0-19.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. (In reply to Björn 'besser82' Esser from comment #0) > Some programs are using the C++ STL and string classes. > Valgrind reports 'still reachable' memory leaks involving these classes at > the exit of the program, but there should be none. I know this is old and fixed long ago, but for the record, the 72kb pool has nothing to do with "STL and string classes". It's allocated by libstdc++ to be able to throw exceptions even when malloc fails to allocate anything more, independent of any use of any STL and string classes. That memory block is allocated if the C++ runtime is linked to the process at all, not because you use any particular classes. > Many implementations of the C++ standard libraries use their own memory > pool allocators. Memory for quite a number of destructed objects is not > immediately freed and given back to the OS, but kept in the pool(s) for > later re-use. The fact that the pools are not freed at the exit of the > program cause Valgrind to report this memory as still reachable. It has nothing to do with pooling allocators. |
Created attachment 1131251 [details] Valgrind supression rule for leaks in C++ STL and string classes Description of problem: Some programs are using the C++ STL and string classes. Valgrind reports 'still reachable' memory leaks involving these classes at the exit of the program, but there should be none. Version-Release number of selected component (if applicable): Any in all maintained releases, including RHEL. How reproducible: 100% Steps to Reproduce: 1. Build a simple C++-program which uses any random STL and/or string-class. 2. Run it using `valgrind --leak-check=full --show-leak-kinds=all`. 3. See a memory-leak similar to the below example. Actual results: 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1 at 0x4C28D06: malloc (vg_replace_malloc.c:299) by 0x50C317F: ??? (in /usr/lib64/libstdc++.so.6.0.21) by 0x400F759: call_init.part.0 (dl-init.c:72) by 0x400F86A: call_init (dl-init.c:30) by 0x400F86A: _dl_init (dl-init.c:120) by 0x4000CB9: ??? (in /usr/lib64/ld-2.22.so) HEAP SUMMARY: in use at exit: 72,704 bytes in 1 blocks total heap usage: 4 allocs, 3 frees, 72,864 bytes allocated LEAK SUMMARY: definitely lost: 0 bytes in 0 blocks indirectly lost: 0 bytes in 0 blocks possibly lost: 0 bytes in 0 blocks still reachable: 72,704 bytes in 1 blocks suppressed: 0 bytes in 0 blocks Expected results: HEAP SUMMARY: in use at exit: 0 bytes in 0 blocks total heap usage: 4 allocs, 4 frees, 0 bytes allocated All heap blocks were freed -- no leaks are possible At least the false positive report of Valgrind should be suppressed by default.supp. Additional info: Many implementations of the C++ standard libraries use their own memory pool allocators. Memory for quite a number of destructed objects is not immediately freed and given back to the OS, but kept in the pool(s) for later re-use. The fact that the pools are not freed at the exit of the program cause Valgrind to report this memory as still reachable. The behavior not to free pools at the exit could be called a bug of the library though. Suggested solution: Add the attached suppression-rule (and brief explanation) to default.supp.