On 06/10/10 11:09, Gordan Bobic wrote: > On 06/10/2010 08:44 AM, Jes Sorensen wrote: >> Not sure if it is worth it, but you might want to look at ElectricFence >> which does malloc wrapping in a somewhat similar way. It might save you >> some code :) > > I'll look into it, but I don't see this requiring more than maybe 50 > lines of code, including comments, headers and Makefile. I was planning > to literally just intercept mmap()/brk()/malloc() and mark them with > madvise() when the underlying call returns. I suspect it will grow in complexity to catch corner cases, but see where it takes you. > Which brings me to another question: > > Would intercepting malloc() be completely redundant if mmap() is > intercepted? Would I also need to do something with intercepting free()? > Is three anything else I would need to intercept? You need to have a look at glibc to see what it is doing. I am not sure what the current malloc implementation is based on these days. >> Whether or not you will run into problems if you run it system wise is >> really hard to predict. Any other application that might be linked in a >> special way or use preload itself might bark, but you can try it out and >> see what explodes. > > Thanks for the heads up. Can you think of any such applications off the > top of your head? Sorry, nothing off hand. A normal Linux distro runs so many applications just at bootup that it's very hard to keep track of what might cause problems. You might end up having to create a blacklist in your library to work around it, but you will only find out when you start trying the boot. Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
