This post contains certain error message when ‘Valgrind’ is called: valgrind: failed to start tool ‘memcheck’ for platform ‘XXXXXX’: No such file or directory. There is a tricky question – can 32-bit valgrind be run on 64-bit platform? The answer is absolutely yes, just like many other 32-bits application do nowadays. However, the answer could not guarantee your ‘valgrind’ working. Let’s go step by step.

<tat09-s00c01h0:lss>/storage/daveti/x86_valgrind/bin:
# uname -a
Linux tat09-s00c01h0 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
<tat09-s00c01h0:lss>/storage/daveti/x86_valgrind/bin:
# file valgrind
valgrind: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped
<tat09-s00c01h0:lss>/storage/daveti/x86_valgrind/bin:
# ./valgrind
valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory

When running 32-bit valgrind on 64-bit platform without any option, we could find the corresponding error reported from valgrind. When valgrind is called without any option, ‘–tool=memcheck’ would be called by default, which will hunt for ‘memcheck-x86-linux’ internally. The fix for this is simple – exporting the corresponding lib dir used by valgrind.

<tat09-s00c01h0:lss>/storage/daveti/x86_valgrind/lib/valgrind:
# file memcheck-x86-linux
memcheck-x86-linux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
<tat09-s00c01h0:lss>/storage/daveti/x86_valgrind/lib/valgrind:
# export VALGRIND_LIB=$PWD
<tat09-s00c01h0:lss>/storage/daveti/x86_valgrind/lib/valgrind:
# cd ../../bin
<tat09-s00c01h0:lss>/storage/daveti/x86_valgrind/bin:
# ./valgrind
valgrind: no program specified
valgrind: Use --help for more information.

<tat09-s00c01h0:lss>/storage/daveti/x86_valgrind/bin:
# ./valgrind ls -l
valgrind: failed to start tool 'memcheck' for platform 'amd64-linux': No such file or directory
<tat09-s00c01h0:lss>/storage/daveti/x86_valgrind/bin:
# which ls
/bin/ls
<tat09-s00c01h0:lss>/storage/daveti/x86_valgrind/bin:
# file /bin/ls
/bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped

When running 32-bit valgrind with ‘ls -l’, which means we tried to detect memory issue for binary ‘ls’, we may get the same error but with slight difference here.  The reason for this error is that ‘ls’ binary is 64-bit and ‘memcheck’ would search for its 64-bit implementation ‘memcheck-amd64-linux’ instead 32-bit one. There is no other way to solve this error rather than building 64-bit valgrind. Once 64-bit valgrind is ready, it looks like below:

<tat09-s00c01h0:lss>/storage/daveti/x86-64_valgrind/lib/valgrind:
# export VALGRIND_LIB=$PWD
<tat09-s00c01h0:lss>/storage/daveti/x86-64_valgrind/lib/valgrind:
# cd ../../bin
<tat09-s00c01h0:lss>/storage/daveti/x86-64_valgrind/bin:
# ./valgrind ls -l
==17314== Memcheck, a memory error detector
==17314== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==17314== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==17314== Command: ls -l
==17314==
total 340
-rwx------ 1 lss lss 40873 Jul 23 10:39 callgrind_annotate
-rwx------ 1 lss lss 11522 Jul 23 10:39 callgrind_control
-rwx------ 1 lss lss 32169 Jul 23 10:39 cg_annotate
-rwx------ 1 lss lss 10417 Jul 23 10:39 cg_diff
-rwx------ 1 lss lss 55965 Jul 23 10:39 cg_merge
-rwx------ 1 lss lss 24211 Jul 23 10:39 ms_print
-rwx------ 1 lss lss 40115 Jul 23 10:39 valgrind
-rwx------ 1 lss lss 23848 Jul 23 10:39 valgrind-listener
-rwx------ 1 lss lss 92633 Jul 23 10:39 vgdb
==17314==
==17314== HEAP SUMMARY:
==17314==     in use at exit: 19,435 bytes in 16 blocks
==17314==   total heap usage: 93 allocs, 77 frees, 66,928 bytes allocated
==17314==
==17314== LEAK SUMMARY:
==17314==    definitely lost: 0 bytes in 0 blocks
==17314==    indirectly lost: 0 bytes in 0 blocks
==17314==      possibly lost: 0 bytes in 0 blocks
==17314==    still reachable: 19,435 bytes in 16 blocks
==17314==         suppressed: 0 bytes in 0 blocks
==17314== Rerun with --leak-check=full to see details of leaked memory
==17314==
==17314== For counts of detected and suppressed errors, rerun with: -v
==17314== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7)