On 01/26/2012 10:16 AM, Baruch Siach wrote:
Only by using valgrind, that I could find the exact location and figure
out, that it was another function that had the problem.
How does the modern memory management system is working then, that it takes
so much time for the problem to surface ?
Now, if you corrupt the internal glibc data structure, glibc won't notice
until you try to call one of malloc(), free(), etc.
And in addition to what Baruch said:
Valgrind will always catch these errors, but will result in significant
slowdown (x10-x20). There are tools like DUMA (and its earlier
incarnation, Electric Fence) incur almost no CPU overhead and can detect
many kinds of corruptions as soon as they happen, by using the memory
management units.
(Because of the MMU granularity, you need to run your program twice -
one in which allocations are aligned to the lower address, and one when
they are aligned to the top address)
There is also a middle ground; gcc's mudflap
<http://www.stlinux.com/devel/debug/mudflap> and -- if your program is
pure C and can be compiled by tcc,
<http://bellard.org/tcc/tcc-doc.html#SEC21>; These are comparable to
valgrind in functionality (for code you compile with them; standard
library code runs at full speed/unchecked), but usually only introduce a
small slowdown (10% or so).
_______________________________________________
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
