Package: valgrind Version: 1:3.3.1-3 Severity: wishlist To reproduce, and actual behaviour (Debian lenny i386):
$ /usr/lib/valgrind/x86-linux/memcheck valgrind: You cannot run '/usr/lib/valgrind/x86-linux/memcheck' directly. valgrind: You should use $prefix/bin/valgrind. $ echo $? 1 $ Desired behaviour, changes marked with "|": $ /usr/lib/valgrind/x86-linux/memcheck valgrind: You cannot run '/usr/lib/valgrind/x86-linux/memcheck' directly. valgrind: You should use $prefix/bin/valgrind. $ echo $? | 255 $ Explanation: I was using valgrind on a complicated program of mine. I ran this command[0]: valgrind --db-attach=yes ./realtime -B -Dmovpos+eval -R -s/dev/ttyUSB0 \ shinkansen.speeds.record santafe.speeds.record bavarian.speeds.record \ homes.record My program attempted to re-exec an earlier copy of itself, but because it was confused, that earlier copy of itself had accidentally been overwritten by a copy of valgrind, specifically, of /usr/lib/valgrind/x86-linux/memcheck. (This was because my program attempts to keep a copy of itself by making a copy of /proc/self/exe; that this didn't work in this case is understandable, or at least likely too hard to fix in valgrind, and is not what this bug report is about.) memcheck obviously didn't like being run like this, resulting in the following output: valgrind: You cannot run '+persist.conv.new' directly. valgrind: You should use $prefix/bin/valgrind. realtime: fatal: persist conversion exited with nonzero status 1 Here "+persist.conv.new" in the current directory is the erroneous copy of memcheck, which my program is trying to execute. My bug report is that memcheck exited 1. It would be better if it exited 127 or 255, which would reduce the odds of a caller mistaking this catastrophic exit status for some special status of its own. You may say that no reasonable program could accidentally execute the memcheck[1] binary directly. But the fact that running valgrind on a program makes /proc/self/exe (and perhaps other things) refer to the memcheck binary can cause the memcheck binary to turn up in unexpected places. As demonstrated here. [1] Or one of the other valgrind tools. This is very much a nit; it is only because valgrind is generally such a high-quality tool that I even bother requesting such a change. Thanks, Ian. [0] For my own future reference. This was with git revision a0977a74fe1007303ac7d96dbff5f97370069b29 of my program. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
