I just upgraded from version 3.0.1-2 and all my attempts to run this new version end up in valgrind receiving the SIGKILL signal. The output of 'strace -f valgrind' ends with: readlink("/proc/self/exe", "/usr/bin/valgrind.bin", 4096) = 21 brk(0) = 0x804d000 brk(0x806e000) = 0x806e000 execve("/usr/lib/valgrind/x86-linux/memcheck", ["/usr/bin/valgrind.bin"], [/* 36 vars */]) = 0 +++ killed by SIGKILL +++ and gdb given no information whatsoever. Running memcheck directly gives the same error, and the strace output is just the execve line. Note that I'm using the 1GB highmem patch that allows computers with up to 1GB of RAM to access it as lowmem instead of using the slower highmem code in the kernel. The previous Valgrind version didn't work with this patch, but at least it gave some form of (not very human-readable) error message. In this regard, this version has a regression. Thanks
*** Bug 117295 has been marked as a duplicate of this bug. ***
Given that there are absolutely no system calls after the call to exec my guess would be that /usr/lib/valgrind/x86-linux/memcheck is never getting control and the kernel is effectively faking up that SIGKILL in which case there isn't much we can do about this. I assume that the problem is that the load address that /usr/lib/valgrind/x86-linux/memcheck is linked for is not available but the kernel really ought to return an error from execve instead of faking up SIGKILL if that is the case. Try changing valt_load_address_normal in configure to something lower and see if that helps.
I had the same problem with kernel 2.6.16-rc4-ck1 (1G/3G low mem enabled, aka CONFIG_VMSPLIT_3G_OPT=y) and valgrind 3.1. Setting valt_load_address_normal to 0x30000000 solved it for me.
We could fix this by changing the default load address on x86 to 0x30000000 (currently is 0xB0000000), but I don't know what other stuff that would break.
More people are running into this now that the VMSPLIT patch is part of >=2.6.16. Only the regular 3G/1G split works.
Fixed (svn r5906): load address changed to 0x38000000 on all targets, which should make it work even if only the lowest 1G of memory is available.