On Thu, Jan 26, 2012 at 10:54:56AM -0500, Ori Berger wrote: > 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).
BTW, in case you do not know Fabric Bellard, he does lots of very cool stuff - he is the author of qemu, and every now and then I give a look at his site. I now did because of this post and found out an amazing project of a PC Emulator in Javascript: http://bellard.org/jslinux/ The guy is simply amazing. -- Didi _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
