https://bugs.kde.org/show_bug.cgi?id=381162
--- Comment #5 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
(In reply to Julian Seward from comment #2)
> But that might explain why it works. And why Philippe's self-hosting
> Memcheck runs never detected it: because LibVEX_Alloc_inline will surely
> have rounded that value up to the next word size (or allocation unit,
> I think 8 or 16 bytes) and in so doing will have removed the effect
> of the "-1". Bizarre, huh!
In the particular case of the lib VEX 'fast allocator', there is
no instrumentation of this allocator : outer memcheck is simply
not informed that the 'big memory piece' is cut in small blocks.
To detect bugs in this area, it will be needed to change
LibVEX_Alloc_inline (in the inner) to:
* add some redzone before/after each block
* increase the permanent and temporary size to cope with the redzone
* use some mempool client requests to inform
the outer memcheck of the allocated blocks
* release all the blocks in one single operation, when the
temporary zone is cleared via vexSetAllocModeTEMP_and_clear
--
You are receiving this mail because:
You are watching all bug changes.
