SUMMARY coregrind/launcher-linux.c calls select_platform() to determine the client platform. select_platform uses the wrong variable in attempting to open the client binary, resulting in no platform detection and fallback to the default platform (e.g. x86-64) if the client is specified as an unqualified filename (i.e. neither an absolute nor relative pathname). The problem and fix are trivial: if (strchr(clientname, '/') == NULL) client = find_client(clientname); else client = strdup(clientname); ... if ((fd = open(clientname, O_RDONLY)) < 0) { return_null: free (client); return NULL; } The first if-statement determines whether the client (clientname) is a bare filename, and if so it invokes find_client to resolve it using $PATH. After this, "client" is either the original name ("clientname") or the resolved pathname. The second if-statement attempts to open the client file. It should use the result of the first if-statement, but instead uses the original parameter to the function. So if the parameter was a bare filename, it attempts to open it from the current directory instead of using the resolved pathame. The second if-statement should be: if ((fd = open(client, O_RDONLY)) < 0) { that is, using "client" rather than "clientname". I've tested this fix in my build of 3.16.0, and confirmed that the bug still exists in the current sources in git. STEPS TO REPRODUCE 1. Use a stock valgrind build on 64-bit x86-64 Linux. This will support both x86-64 and x86-32 platforms, defaulting to '64. 2. Build a trivial 32-bit C program in a subdirectory. For example: mkdir tmp echo 'int main(void) {return 0;}' > tmp/nop.c cc -o tmp/nop -m32 tmp/nop.c 3. Attempt to memgrind it (this must NOT be done in the directory containing the client, or you'll get a false negative): PATH=$PWD/tmp:$PATH valgrind -d nop You should get the wrong-platform message, and the debug output should include "no platform detected, defaulting platform to 'amd64-linux'". OBSERVED RESULT Valgrind fails because it's failing to detect the client platform. EXPECTED RESULT Valgrind should correctly open the client and detect the platform. (Run with higher debug levels, e.g. "-d -d", to see what select_platform is doing.)
Thanks for the report. It seems I accidentally introduced this bug with: commit f15beea767892ae52ed1d92d789114685fb5dc82 Author: Mark Wielaard <mark@klomp.org> Date: Sat May 25 16:31:02 2019 +0200 Fix memory leak in launcher-linux.c When the clientname argument is not a full absolute path we reconstruct the full path using $PATH. This reconstructed full path would be leaked. This is small and insignificant. But valgrind should give a good example. So free the path again when we are done and allocated the memory. Also don't print the path twice in the debug output if we didn't need to construct a new different path for it. I am not sure why this wasn't noticed earlier because your example clearly shows it failing. I guess 32-on-64 arch runs are just not done that much or always involve a relative or absolute path?
commit f7e87e6ae3497287ceac6ef266d4f10ee8ab3c53 Author: Mark Wielaard <mark@klomp.org> Date: Thu Feb 4 16:14:00 2021 +0100 PR422261 platform selection fails for unqualified client name Bug introduced with commit f15beea76 "Fix memory leak in launcher-linux.c" Need to try opening the actual 'client' path, not just the 'clientname' file name. Reported-by: Michael Wojcik <michael.wojcik@microfocus.com> https://bugs.kde.org/show_bug.cgi?id=422261