> uname -a:
> Linux TB2SEE1 2.6.16.46-0.12-smp #1 SMP Thu May 17 14:00:09 UTC 2007 x86_64
> x86_64 x86_64 GNU/Linux
>
> rpm -q glibc:
> glibc-2.4.31.43.6.PTE.473402.0
>
> /lib64/libc.so.6->libc.2.4.so
That information shows that the software environment is about 7 years old.
While valgrind-3.9.0 is the latest release, and problems with the latest
release always are relevant, the old age of the user application environment
likely
will make it more difficult to catch and hold the attention of valgrind
developers.
Here are two things that can be done to increase interest:
1) Construct a small test case which reproduces the problem. Extract code
from the application, or write a new program. Something like 50 to 100 lines
should be enough. In some cases using 'strace' on the application (or on
valgrind running the application) may provide hints about what is important
just before the error. In other cases using a debugger such as 'gdb'
may give insights about what is happening. Pay particular attention
to signals, threading (if any), and other less-common events.
2) Reproduce the problem using recent glibc. Determine the shared libraries
that the application uses by running "ldd ./my_application". Intersect
that with the shared libraries provided by glibc, which are listed by: "rpm -ql
glibc".
Then go to another machine that has recent glibc installed,
and copy the intersected shared libraries from the newer glibc installation
onto a new directory $NEWDIR on the _old_ machine. In that new directory
$NEWDIR
on the old machine, also create any symbolic links that are relevant,
such as libc.so -> libc-2.NN.so.
Then run valgrind running the old application using the newer glibc by:
$NEWDIR/ld-linux-x86-64.so.2 --library-path $NEWDIR:$LD_LIBRARY_PATH \
valgrind _valgrind_options_ ./my_application _application_arguments_
Read the hints given by:
$NEWDIR/ld-linux-x86-64.so.2
You can test the shared library dependencies using
$NEWDIR/ld-linux-x86-64.so.2 --library-path $NEWDIR:$LD_LIBRARY_PATH
--list ./my_application
to verify that all the shared libraries are coming from the correct directories.
If the problem persists when using current glibc, then that increases the
motivation
of valgrind developers to investigate. If the problem goes away when using
current glibc,
then a) you have a running valgrind on the application, and b) why not install
the newer glibc?
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
