Fix a bug in the "numbering" dedup pool: as indicated in
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
1 file changed