https://bugs.kde.org/show_bug.cgi?id=392855
--- Comment #8 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- (In reply to David Rankin from comment #7) > Created attachment 114754 [details] > xtmemory.kcg.16050 > > Attached is the xtmemory.kcg.16050. The same problems continue in gcc (GCC) > 8.2.0 with Valgrind-3.14.0.GIT and LibVEX. The problem appears to be the > allocations for the printf family. This is running on Linux 4.18.5 > (Archlinux) on AMD x86_64. Re-reading this bug, I am not sure to understand the problem you have. If your program is using a library function, and this library function allocates some memory (and this memory is freed at exit), then all looks normal to me, and that is the expected behaviour of Valgrind/memcheck. As I understand, the initial program compiled with optimisation did only one single malloc (and free), due to printf. When compiled without optimisation, it does 2 malloc/free: * one malloc/free (needed for internal printf work) * the malloc/free in your program. So, in summary, all looks ok to me. If glibc or whatever would not release the memory (which it does), then that might give a memory leak, but again, this memory is all freed (via glibc cleanup routine called by Valgrind). So, I do not know what is supposed to be fixed. -- You are receiving this mail because: You are watching all bug changes.