Version: r9493, retrieved 2009-03-22 (using Devel) Compiler: Ubuntu 4.3.2-1ubuntu12 Ubuntu 8.10 x86_64 OS: Linux Installed from: Compiled sources You can retrieve the full log and the 32 bit app I was trying to run at http://kegel.com/valgrind/bad-2009-03-26.tgz The command was valgrind -v --track-origins=yes ./base_unittests.exe and it fails very quickly. The error was: MC_(get_otrack_shadow_offset)(x86)(off=320,sz=4) Memcheck: mc_machine.c:672 (get_otrack_shadow_offset_wrk): the 'impossible' happened. at 0x38026FCD: report_and_quit (m_libcassert.c:140) by 0x380272CE: vgPlain_assert_fail (m_libcassert.c:205) by 0x380203B1: vgMemCheck_get_otrack_shadow_offset (mc_machine.c:672) by 0x3801F630: vgMemCheck_instrument (mc_translate.c:4295) by 0x380B8DC3: LibVEX_Translate (vex_main.c:500) by 0x3803E7A4: vgPlain_translate (m_translate.c:1506) by 0x3804F46D: vgPlain_scheduler (scheduler.c:796) by 0x3806C308: run_a_thread_NORETURN (syswrap-linux.c:89)
Also tested several other revisions by doing svn up -rXXXX Results: r9436 bad r9350 bad r9250 build fail - No rule to make target `libvex_x86_linux.a' It looks like the svn command I used to retrieve an old version might not also retrieve the old version of VEX? What's the proper procedure for retrieving an old revision of valgrind plus the matching version of VEX?
I'm not sure if updating for different versions like that works... at the least, you'll have to 'make clean' for everything to work, that should fix the libvex_x86_linux.a problem I think.
I did 'make distclean' before each build, so that wasn't it. So is there really no way to go back in time? I'm starting to wonder if svn has a gigantic hole in it.
Going back in time should work fine, but you may need to find out what the corresponding VEX revision is and go back to that as the VEX tree is a separate repository that is pulled in via an external. Obviously there is no guarantee that any specific arbitrarily chose revision will build/work ;-)
How does one find out the corresponding VEX version? The hole I'm talking about is that VEX is pulled in fine if you're checking out or updating, but not if you're trying to go back to a specific revision. I suspect I'm going to end up with a shell script that does the right thing, but this should have been integrated into svn.
You would have to look at the dates in the log and see what version was current at the date the relevant valgrind version was committed. What you're asking for is basically not possible - well it is, but it would mean that every time somebody committed a change to VEX they had to update valgrind's external to point at that specific revision in the VEX repository. Basically an svn external (like the VEX directory) is just a pointer that says "checkout this other piece of software here" and it will checkout the head of whatever branch it is pointing at unless it is hardwired to a specific version in which case it will need changing all the time.
Nah, it's easy-ish if you're willing to specify a date instead of a revision. To fetch valgrind as of Jan 1 2009, do: svn up -r '{2009-01-01}'; cd VEX; svn up -r '{2009-01-01}' Here's the script I'm using during regression testing: #!/bin/sh set -ex make distclean || true svn up -r "{$1}" cd VEX svn up -r "{$1}" cd .. sh autogen.sh ./configure --prefix=/usr/local/valgrind make -j5 And here are the results: 2009-03-27: bad 2009-03-01: good 2009-03-10: good 2009-03-20: bad 2009-03-15: good 2009-03-17: good 2009-03-19: good So the problem happened between 2009-03-19 and 2009-03-20. $ svn diff -r '{2009-03-19}:{2009-03-20}' ; cd VEX; svn diff -r '{2009-03-19}:{2009-03-20}' shows possible culprits. Poking around in http://news.gmane.org/gmane.comp.debugging.valgrind.devel in that date range found the interesting commit "vex: r1886 - in trunk: priv/guest-amd64 priv/guest-ppc priv/guest-x86 pub ... This commit will break the Valgrind svn trunk (temporarily)." So I guess this outage was planned?
Fixed (r9497).