|
From: Jeremy F. <je...@go...> - 2005-01-10 00:15:31
|
On Sun, 2005-01-09 at 19:01 +0000, Julian Seward wrote: > That's really amazing. What changes beyond the threading one did you > have to make? Nothing major. A few little bugfixes around the place (ironic that vg_to_ucode can't parse the code generated by vg_from_ucode). > So, can you complete the trick by making the inner V do allocation > via malloc/free (or whatever) in such a way that the outer V can > memcheck it and find real bugs therein? Yes, but I haven't done that much. I tried annotating vg_malloc2.c, but got stuck trying to work it all out and figured that you or Nick would be better people to do it. In particular, I don't understand how to use MALLOCLIKE and FREELIKE in practice. How do you prevent Valgrind from complaining about the allocator itself touching the metadata near the alloced blocked? I did do a quick hack by just making arena_malloc/free call malloc/free, (and dropping arena_malloc_aligned, since it isn't used anywhere). It comes out surprisingly clean when running little programs. There's a few small leaks, but nothing shocking. Anyway, all the patches are at http://www.goop.org/~jeremy/valgrind . J |