|
From: Ashley P. <as...@qu...> - 2005-08-25 07:52:39
|
On Wed, 2005-08-24 at 13:08 -0500, Nicholas Nethercote wrote:
> On Wed, 24 Aug 2005, Ashley Pittman wrote:
>
> > Is it possible to write suppressions at line number resolution rather
> > than just the function names
>
> No. But Joseph M Link wrote a patch just recently that lets you do this
> (see "Patch to support suppressions by source file" on valgrind-users).
> Perhaps this should go into the repository.
I can't see any harm in this functionality and indeed from your own
website: "Each error to be suppressed is described very specifically, to
minimise the possibility that a suppression-directive inadvertantly
suppresses a bunch of similar errors which you did want to see. The
suppression mechanism is designed to allow precise yet flexible
specification of errors to suppress."
> > Also, one thing I've spotted, if an error is found in a installed shared
> > library the report only shows the filename but if the library is loaded
> > from a LD_LIBRARY_PATH setting it gets a full filename:line_number. Is
> > there a way to turn this behaviour on by default?
By "only shows the filename" here I do of course mean the shared library
filename, not the source code filename.
> That isn't intentional, it sounds like a bug. Can you give a more
> specific example?
Ok, here's what I'm doing
$ echo $LD_LIBRARY_PATH
/opt/intel/compiler81/lib
$ ldd `which mping`
libmpi.so.1.0 => /usr/lib/mpi/default/lib/libmpi.so.1.0
(0x40025000)
libmpio.so.1.0 => /usr/lib/mpi/default/lib/libmpio.so.1.0
(0x40083000)
libelan.so.1 => /usr/lib/libelan.so.1 (0x400af000)
libm.so.6 => /lib/i686/libm.so.6 (0x40102000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
libimf.so => /opt/intel/compiler81/lib/libimf.so (0x40124000)
librmscall.so.1 => /usr/lib/librmscall.so.1 (0x402ca000)
libelanctrl.so.2 => /usr/lib/libelanctrl.so.2 (0x402cf000)
libelan4.so.1 => /usr/lib/libelan4.so.1 (0x402d6000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ prun -N2 ~duncant/valgrind_install/bin/valgrind mping
<snip>
==27906== Conditional jump or move depends on uninitialised value(s)
==27906== at 0x1B9CFB3E: elan_createSubGroup
(in /usr/lib/qsnet/elan4/lib/libelan.so.1)
==27906== by 0x1B91D48E: MPID_CommInit (adi2init.c:1491)
==27906== by 0x1B93B8E3: MPIR_Init (initutil.c:403)
==27906== by 0x1B93B00B: MPI_Init (init.c:163)
==27906== by 0x8048ECC: main (in /usr/lib/mpi/mpi_intel/bin/mping)
<snip>
$ mkdir tmp/v_test
$ cp /usr/lib/qsnet/elan4/lib/libelan.* tmp/v_test
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/ashley/tmp/v_test
$ prun -N2 ~duncant/valgrind_install/bin/valgrind mping
<snip>
==27908== Conditional jump or move depends on uninitialised value(s)
==27908== at 0x1B9CFB3E: elan_createSubGroup (common/groupSub.c:192)
==27908== by 0x1B91D48E: MPID_CommInit (adi2init.c:1491)
==27908== by 0x1B93B8E3: MPIR_Init (initutil.c:403)
==27908== by 0x1B93B00B: MPI_Init (init.c:163)
==27908== by 0x8048ECC: main (in /usr/lib/mpi/mpi_intel/bin/mping)
<snip>
The differencing being "(in /usr/lib/qsnet/elan4/lib/libelan.so.1)" in
the first trace and "(common/groupSub.c:192)" in the second.
At first I thought this was a neat trick that valgrind was doing but
that isn't so, the MPI routines come from a installed library as well
and they don't get the same treatment.
/usr/lib/libelan.so.1 is a symbolic link which eventually points
to /usr/lib/qsnet/elan4/lib/libelan.so.1, setting my LD_LIBRARY_PATH
to /usr/lib/qsnet/elan4/lib/ directly I get the first style of output.
Ashley,
|