On 01/04/11 06:27, John Reiser wrote: > There is an interaction between realloc and memcheck that probably accounts > for this. When the test program runs without valgrind, probably m14 > soon resides at an "end" of the address space, such that each subsequent > realloc which increases the size of m14 can succeed by placing new pages > adjacent to the existing end, where the size of the new pages is about > the _difference_ between the new size and the old size. The old data bytes > do not move; the return value of the realloc() equals the value of the > first argument. > > When the test program is run under valgrind, then valgrind must allocate some > space to hold the accounting data for each block. The accounting data is > 9 bits per byte, so if a block is large then the accounting data is large. > In particular, it is plausible that the realloc(m14,...) and the accounting > data "checkerboard" the address space so that each realloc must get enough > pages for the entire new size, copy the old bytes from *m14 to the new pages, > free() the old m14, and return a pointer to the new pages.
Actually that probably won't happen because valgrind tries to use separate memory areas for client data and it's own data. It doesn't matter though, because valgrind's realloc deliberately forces all calls to do malloc+copy+free rather than resize in place in order to better detect bugs. Tom -- Tom Hughes ([email protected]) http://compton.nu/ ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
