https://bugs.kde.org/show_bug.cgi?id=520170
--- Comment #1 from Paul Floyd <[email protected]> --- (In reply to Michael Catanzaro from comment #0) > DESCRIPTION > > I'm trying to run GNOME Builder under valgrind 3.27.0 because I strongly > suspect there is a memory corruption issue somewhere in vte. I think > valgrind might be printing false positive complaints about mismatched > free/delete/delete[]. I hope not. > I've been doing some squinting, and it doesn't appear > to be a mismatch. The most common cause of issues like this is that some combination of the compiler, linker and library is presenting inconsistent information to Valgrind. Inconsistent as in what Valgrind sees in the machine code does not match what was written in the source code. Possible causes for this are 1. Mixing use of sibling calls between allocation and deallocation. I'd say that this is the most likely, at least for the reason that the deallocation is not seen as operator delete. For instance I've seen this in a large project like this, mixing static and dynamic versions of libstdc++ Let's say your app links with liba and libb and they link liba -> dynamic libstdc++.so libb -> static libstdc++.a In this configuration if you have an object allocated in liba then Valgrind will see all of the allocation function symbols. If that object is then deallocated in libb there may be some optimisations such is sibling calls that hide call information from valgrind. Specifically in this case that could be deallocate -> sibling call to sized operator delete[] -> normal call to free_sized. Valgrind does not see the sibling call to operator delete[] and so it reports is mismatch. 2. If you use "identical code folding" then the linker might be seeing that deallocation functions have identical machine code and only generating one version. 3. If you use tcmalloc, that manually does identical code folding and only generates one alias for free/delete/delete[]. The reason why Valgrind sees operator delete[] rather than operator delete could be identical code folding. To be certain of what is happening you need to examine the assembler to see what is really being called (ot, in the case of sibling calls, jumped to). > I also wondered: is it possible that the memory was allocated in code built > by one compiler, and deallocated in code built by a different compiler, such > that the definitions really do become mismatched? But in this example, both > allocation and deallocation occur in vte's termpropsregistry.cc, so it's the > same source code file. All the compilers that Valgrind supports use GCC name mangling so that should not be an issue. -- You are receiving this mail because: You are watching all bug changes.
