https://bugs.kde.org/show_bug.cgi?id=509666
--- Comment #10 from Paul Floyd <[email protected]> --- (In reply to Aliaksei Kandratsenka from comment #9) > Hi. I am gperftools maintainer. > > We should perhaps coordinate what is the intended behavior here. > > The code that gets into infinite loop explicitly does tc_free and tc_malloc > because it assumes it will call _our_ code. > > The expectation is if whoever is overriding memory allocation APIs they'll > have malloc/free etc, but not tc_XYZ functions. > > I am wondering why valgrind etc isn't "simply" doing that. I.e. have linker > "find" malloc and other functions where you need them to be as opposed to > using code rewriting magic. > > Depending on the logic here we can further establish what fixes (if any) > need to be done to gperftools. Why don't we do "simple" things like use the linker? Because that would cause a lot of problems. Quick overview of how Valgrind works. It is a static binary that does not link to any libraries. That way we can be sure that there are no conflicts between libc or libc++ internal state should they used by Valgrind and used by the guest. Valgrind does the same job as the OS regarding loading the guest exe. This has two big advantages. Firstly we get to see the whole picture for all memory. Tools that start after the guest exe has loaded have to handle memory whose origins they have not recorded. This also means that we check any startup code in guest exes. The other big advantage is that we don't rely on dynamic linking tricks. We can load static exes as well. We just look at all of the ELF symbols and record the ones that we need to redirect. In your libraries you use aliases so malloc and tc_malloc are the same from our perspective. Same for free with 8 aliases. We could probably detect these aliases (and that could be useful for the free/new/new[] aliases). As long as you are using these aliases it is impossible for us to tell them apart. If we replace malloc then we also replace tc_malloc since they are the same. -- You are receiving this mail because: You are watching all bug changes.
