Hi Wim,
Yes, valgrind was build from source (Gentoo). I rebuilt it to check. Here are some key outputs:
[quote]./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --disable-dependency-tracking --without-mpicc
…
Primary build target: AMD64_LINUX
Secondary build target: X86_LINUX
[/quote]
The problem seems to be with the use of /lib/ld-linux.so.2:
~ $ ls -l /lib/ld-linux.so.2
lrwxrwxrwx 1 root root 22 May 5 21:42 /lib/ld-linux.so.2 → …/lib32/ld-linux.so.2
Otherwise, things look to be pure 64bit:
~ ls -l /usr/lib
lrwxrwxrwx 1 root root 5 Nov 16 2011 /usr/lib -> lib64
~ ldd which root
linux-vdso.so.1 (0x00007fff97193000)
libXpm.so.4 => /usr/lib64/libXpm.so.4 (0x00007f3c2c717000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f3c2c3d8000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/libstdc++.so.6 (0x00007f3c2c0d3000)
libc.so.6 => /lib64/libc.so.6 (0x00007f3c2bd28000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f3c2bb07000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f3c2b903000)
libm.so.6 => /lib64/libm.so.6 (0x00007f3c2b613000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3c2c929000)
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/libgcc_s.so.1 (0x00007f3c2b3fd000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f3c2b1f9000)
libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f3c2aff3000)
~ ldd `which python`
linux-vdso.so.1 (0x00007fffd19ff000)
libc.so.6 => /lib64/libc.so.6 (0x00007fdbbdf39000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdbbe2e4000)
~ ldd which valgrind
linux-vdso.so.1 (0x00007fffd1531000)
libc.so.6 => /lib64/libc.so.6 (0x00007f9f729f4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9f72d9f000)
So I guess the question is: why did valgrind decide to use /lib/ld-linux.so.2?
Looking at valgrind logs, it also uses /usr/bin/ldd or /lib64/ld-linux-x86-64.so.2
And what is it about the content of test_su that triggers this?
Just to double check, I created another similar test:
~/d0/afb $ diff test0.py test1.py
5c5
< import test_su as SU
---
> import test_su1 as SU
~/d0/afb $ less test_su1.py
import ROOT as R
def save_canvas( name = 'tmp', fig_out_dir = 'fig', formats = [ 'eps', 'png' ] ):
can = R.gPad.GetCanvas()
can.cd()
for form in formats:
can.SaveAs( '{}/{}.{}'.format( fig_out_dir, name, form ) )This starts the same way, but then valgrind does not issue a:
but proceeds directly to run the python program.
valgrind_test0_new.txt (13.1 KB)
valgrind_test1.txt (8.17 KB)