https://bugs.kde.org/show_bug.cgi?id=375415
Bug ID: 375415
Summary: free list of blocks, mempool blocks and describe addr
do not work properly together
Product: valgrind
Version: 3.12.0
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: NOR
Component: memcheck
Assignee: jsew...@acm.org
Reporter: philippe.waroqui...@skynet.be
Target Milestone: ---
There are several strange things in the interaction between free list
of blocks, mempool blocks and describe addr.
* MC_(get_freed_block_bracketting) always uses the redzone
sizeMC_(Malloc_Redzone_SzB).
For a mempool block, the redzone size to use should be the one from the
mempool.
This can cause either False positive or False negative matching between an
addr and
a mempool block.
* For an unclear reason, the introduction of the meta pool functionality has
changed
the below code by adding the && !MC_(is_mempool_block)(mc) condition. It is
unclear
why a freed mempool block would not be a good candidate to describe an
(erroneous)
address.
/* -- Search for a recently freed block which might bracket it. -- */
mc = MC_(get_freed_block_bracketting)( a );
if (mc && !MC_(is_mempool_block)(mc)) {
* It is also not very clear in which order the address description should be
done.
The code searches in meta mempool last. But it the meta mempool has been
created from
a big malloc superblock, then it looks to me that it would be better to first
search
in the allocated 2nd level blocks (as this is a real application memory),
before finding
the meta pool block.
Probably we need a somewhat heavy rework of the way addresses are described.
Maybe we should always search all types of blocks (allocated or freed,
classical or mempool),
and then decide a priority order to display the info.
See also bug 322245
--
You are receiving this mail because:
You are watching all bug changes.
