zenithsiz/ftmemsim-valgrind
1
0
Fork 0
mirror of https://github.com/Zenithsiz/ftmemsim-valgrind.git synced 2026-02-03 18:13:01 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fix a bug in the "numbering" dedup pool: as indicated in

Browse Source 
pub_tool_deduppoolalloc.h, for "numbering" pool, there is no guarantee
that the address of an element is stable if a new element is inserted.
But m_deduppoolalloc.c was itself not taking this 'no guarantee' into account.
So, when the addresses of the elements are changed due to reallocation
of the only pool, apply an offset to the element addresses stored in
the dedup hash table.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14127
This commit is contained in:
Philippe Waroquiers 2014-07-04 20:40:02 +00:00
parent 9ab8999e43
commit cae97b0c66
1 changed files with 15 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
coregrind/m_deduppoolalloc.c
View File

@ -149,9 +149,17 @@ static void ddpa_add_new_pool_or_grow ( DedupPoolAlloc* ddpa )
UChar *newpool = ddpa->alloc (ddpa->cc, 2 * curpool_size);
UChar *newpool_free = ddpa_align (ddpa, newpool);
UChar *newpool_limit = newpool + 2 * curpool_size - 1;
Word reloc_offset = (Addr)newpool_free - (Addr)curpool_align;
ht_node *n;
vg_assert (newpool);
VG_(memcpy) (newpool_free, curpool_align, curpool_used);
/* We have reallocated the (only) pool. We need to relocate the pointers
in the hash table nodes. */
VG_(HT_ResetIter) (ddpa->ht_elements);
while ((n = VG_(HT_Next) (ddpa->ht_elements))) {
n->elt = (void*)((Addr)n->elt + reloc_offset);
}
newpool_free += curpool_used;
VG_(dropHeadXA) (ddpa->pools, 1);