https://bugs.kde.org/show_bug.cgi?id=375415
--- Comment #4 from Ruurd Beerstra <ruurd.beers...@infor.com> --- Sorry for the delay, I'm doing lots of stuff on other projects and valgrind is on the back burner for me. It "just works" as part of our regression framework, doing several thousand runs every night and catches newly introduced memory errors every so often. So I hope I can still make sense here :-) Point 1 (bad redzone): My bad, caused by being all new to valgrind when I took a stab at modifying it. Our code doesn't use redzones, so both are zero and I didn't look closely enough. Needs a fix. Point 2: The not-is-mempool test: Unless I'm completely wrong here: If I take that test out, many application-malloced blocks that lie within a mempool block will be described as lying within a mempool block, with the allocation stack being the one that triggered the allocation of that mempool block (some random moment when the pool is exhausted). That is not what I want: I want the description of the malloc that was done *from* the mempool block, with the proper allocation stack. This is because our allocator uses itself to allocate the mempool blocks, so both mempool-block allocs and plain application allocs are on the same malloc list. The test for a mempool block at the end was added to catch the case where an application-malloc is NOT within a mempool, which should not happen in our custom-allocator case, but the case needs handling. Your remark: "what you have removed is that a mempool (inner for meta pool) block is never landing in an error address description" is correct: I consider that address description an internal and uninteresting affair of our custom allocator and there should always be a more interesting, application malloc stack that I want to show. Does that make sense? Point 3: About the order: I think you sort of echo there what I try to describe above. This is hard stuff, trying to get the best address description in all cases. All I can say: The current version works for me, and I gather there are few custom allocators these days that use the mempool features. But if my amateur changes require rework: feel free to improve upon it. I'll (test) run it in our test environment. -- You are receiving this mail because: You are watching all bug changes.
