|
From: Jeremy F. <je...@go...> - 2005-01-08 19:55:56
|
It turns out the threading changes made this pretty simple to get working: $ valgrind --tool=none --single-step=yes valgrind --tool=none echo 'I simulate, therefore I am.' ==11451== Nulgrind, a binary JIT-compiler for x86-linux. ==11451== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. ==11451== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==11451== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==11451== For more details, rerun with: -v ==11451== >==11451== Nulgrind, a binary JIT-compiler for x86-linux. >==11451== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. >==11451== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. >==11451== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. >==11451== For more details, rerun with: -v >==11451== I simulate, therefore I am. >==11451== ==11451== |
|
From: Julian S. <js...@ac...> - 2005-01-09 19:01:17
|
That's really amazing. What changes beyond the threading one did you have to make? 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? J > I simulate, therefore I am. |
|
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 |
|
From: Nicholas N. <nj...@ca...> - 2005-01-10 12:26:24
|
On Sun, 9 Jan 2005, Jeremy Fitzhardinge 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). I would have thought the memory layout inflexibilities would have caused problems. Where in the address space are the two Valgrinds going? >> 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. Can you try doing a meaningless jump on an uninitialised variable, or something else that doesn't involve malloc? It would nice reassuring to know that it really is working ok. N |
|
From: Jeremy F. <je...@go...> - 2005-01-10 16:39:49
|
On Mon, 2005-01-10 at 12:26 +0000, Nicholas Nethercote wrote: > > Nothing major. A few little bugfixes around the place (ironic that > > vg_to_ucode can't parse the code generated by vg_from_ucode). > > I would have thought the memory layout inflexibilities would have caused > problems. Where in the address space are the two Valgrinds going? It works out naturally. The first Valgrind grabs the top of the address space, and the next one takes the chunk below that; PIE means they can relocate themselves. The only change I had to make was to ignore /proc/self/maps entries above VG_(valgrind_last). > Can you try doing a meaningless jump on an uninitialised variable, or > something else that doesn't involve malloc? It would nice reassuring to > know that it really is working ok. Oh, it definitely works. There are messages coming out, but it mostly looks like ld.so suppressable chaff. And I fixed a leak after I did the malloc/free substitution. J |
|
From: Julian S. <js...@ac...> - 2005-01-10 16:53:30
|
> Oh, it definitely works. There are messages coming out, but it mostly > looks like ld.so suppressable chaff. And I fixed a leak after I did the > malloc/free substitution. Good. What leak is that? I would be interested to see it. J |
|
From: Jeremy F. <je...@go...> - 2005-01-10 18:03:25
|
On Mon, 2005-01-10 at 16:53 +0000, Julian Seward wrote:
> > Oh, it definitely works. There are messages coming out, but it mostly
> > looks like ld.so suppressable chaff. And I fixed a leak after I did the
> > malloc/free substitution.
>
> Good.
>
> What leak is that? I would be interested to see it.
There were a handful of small leaks, but the biggest was this:
if(VG_(strncmp)(si->symtab[i].name, VG_INTERCEPT_PREFIX,
VG_INTERCEPT_PREFIX_LEN) == 0) {
int len = VG_(strlen)(si->symtab[i].name);
char *buf = VG_(malloc)(len), *colon;
intercept_demangle(si->symtab[i].name, buf, len);
colon = buf + VG_(strlen)(buf) - 1;
while(*colon != ':') colon--;
VG_(strncpy_safely)(si->symtab[i].name, colon+1, len);
}
in vg_symtab2.c:canonicaliseSymtab(). (The "while(*colon != ':')..."
loop looks a bit dubious to me as well, since it will fail to terminate
if there's no ':'.)
But bear in mind I haven't run anything very complex under V+V yet, so
it hasn't really been exercised at all.
J
|