https://bugs.kde.org/show_bug.cgi?id=372347
--- Comment #5 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- (In reply to Christopher Smith from comment #4) > (In reply to Philippe Waroquiers from comment #3) > > If your new/delete operators will have the 'normal/expected' semantic, > > then why would the Valgrind replacement create a problem ? > > Or, in other words, what is special in your operators that make them > > non replaceable ? > > You lose a lot of Valgrind functionalities if you do not replace > > the heap functions. > > Certain parts of my program do a lot of allocation/deallocation. I plan on > adding a sort of "cache" for same sized sections of memory to prevent having > to run malloc each time. Although I suppose this is purely a performance > optimization and can be omitted during testing. If the only thing that your replacement functions are doing is to do a (local) cache of small objects, then it should be no problem to have them replaced by Valgrind, and then benefit from all the Valgrind features (leak search, redzone protection, etc). It is only when your specific heap does very special actions (such as for example releasing all small blocks at once) that no replacement should be done. For such special heaps, you then must use the various *MEMPOOL* requests to allow valgrind to (somewhat) understand your specific heap. > > For now, I'll use `--show-mismatched-frees=no`. I'm looking forward to this > fix. -- You are receiving this mail because: You are watching all bug changes.
