|
From: Philippe W. <phi...@sk...> - 2012-07-28 16:06:17
|
Currently, tools which are replacing malloc (VG_(needs_malloc_replacement) can control the size of the redzone CLIENT arena, but this is all defined at compile time. Similarly, the redzone size for the core arenas (CORE, TOOL, DINFO, ...) is also defined at compile time. The attached patch implements two command line options: --client-redzone=<number> and --core-redzone=<number> The first clo can be used to either decrease the memory used by Valgrind or increase the protection or chance to discover heap overrun/underrun. The default behaviour is unchanged : if no clo is given, same as 3.7.0 (so, value of the tool provided redzone size is used). If --client-redzone is given, it overrides (at arena init) the default value provided by the tool. The decrease is particularly useful for applications doing a lot of small block allocations and using tools with a big redzone (such as helgrind or memcheck) while it is believed (e.g. as memcheck was already used) that no heap over/under-run occurs. The second option allows to (better) chase bugs inside Valgrind core and tools (by increasing the redzone size for the internal Valgrind arena), if ever it would be needed. One new test added to verify the clo has an effect on memcheck. Regression tested on x86 and amd64. Verified with --profile-heap=yes that mapped memory increases or decreases according to the clo option size. All tests also have run with --client-redzone=0 and 128 and with --core-redzone=128. A few tests are failing (for normal reasons) because the memory layout is changing Feedback welcome One question: I have currently limited the max value of the redzone to 128 bytes (similar to the assert on the tool received value). I am wondering if we should not allow more (e.g. up to a page of 4Kb ?) from the clo ? Philippe |