|
From: Lee K. <lki...@cs...> - 2003-07-21 09:50:15
|
Guys, have been seeing so real wiredness with VG 1.9.6 and in the recently released snapshot. Background: I've got a threaded server which in turn also forks off clients to "process" files. The fork actually calls a script which in turn sets up the environment and then calls the appropriate binary. Now, the binary was failing to load its shared libraries. I've dumped out the environment outwith vg, and within the script (which is now running "under" vg, but withut the follow child option), the differences: *** env.sorted 2003-07-21 10:42:25.000000000 +0100 --- env-vg.sorted 2003-07-21 10:42:11.000000000 +0100 *************** *** 8,14 **** HOSTTYPE=i386-linux LAMHELPFILE=/etc/lam/lam-helpfile LANG=en_GB.UTF-8 ! LD_LIBRARY_PATH=/home/lofs/lofs_1.1.4-20030721a/lib: LESSOPEN=|/usr/bin/lesspipe.sh %s LOFS_DATA_DIR=/home/lofs LOFS_HOME_DIR=/home/lofs/lofs_1.1.4-20030721a --- 8,16 ---- HOSTTYPE=i386-linux LAMHELPFILE=/etc/lam/lam-helpfile LANG=en_GB.UTF-8 ! LD_ASSUME_KERNEL=2.2.5 ! LD_LIBRARY_PATH= /home/lofs/lofs_1.1.4-20030721a/lib: ! LD_PRELOAD= /usr/mlocal/lib/valgrind/valgrinq.so: LESSOPEN=|/usr/bin/lesspipe.sh %s LOFS_DATA_DIR=/home/lofs LOFS_HOME_DIR=/home/lofs/lofs_1.1.4-20030721a *************** *** 23,32 **** PWD=/home/lofs QTDIR=/usr/lib/qt-3.1 SHELL=/bin/tcsh ! SHLVL=1 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SUPPORTED=en_GB.UTF-8:en_GB:en TERM=xterm USER=lofs VENDOR=intel ! XAUTHORITY=/home/lofs/.xauthp1zf4n --- 25,35 ---- PWD=/home/lofs QTDIR=/usr/lib/qt-3.1 SHELL=/bin/tcsh ! SHLVL=2 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SUPPORTED=en_GB.UTF-8:en_GB:en TERM=xterm USER=lofs VENDOR=intel ! VG_ARGS= --suppressions=/usr/mlocal/lib/valgrind/default.supp --num-callers=10 ! XAUTHORITY=/home/lofs/.xauth2aTeKl Note the spaces before LD_LIBRARY_PATH - this is causing the libraries to be missed! Something up with the "mashing" that is done? Currently the script only adds to LD_LIBRARY_PATH if the appropriate path isn't already there - changing this to always setup LD_LIBRARY_PATH from scratch causes the binary to run as expected. System is Red Hat 9: Linux kelvin 2.4.20-9 #1 Wed Apr 2 13:42:50 EST 2003 i686 i686 i386 GNU/Linux Thanks, Lee. |
|
From: Nicholas N. <nj...@ca...> - 2003-07-21 09:56:26
|
On Mon, 21 Jul 2003, Lee Kindness wrote: > Guys, have been seeing so real wiredness with VG 1.9.6 and in the > recently released snapshot. > > *** env.sorted 2003-07-21 10:42:25.000000000 +0100 > --- env-vg.sorted 2003-07-21 10:42:11.000000000 +0100 > *************** > *** 8,14 **** > ! LD_LIBRARY_PATH=/home/lofs/lofs_1.1.4-20030721a/lib: > --- 8,16 ---- > ! LD_LIBRARY_PATH= /home/lofs/lofs_1.1.4-20030721a/lib: > *************** > *** 23,32 **** > > Note the spaces before LD_LIBRARY_PATH - this is causing the libraries > to be missed! Something up with the "mashing" that is done? Currently > the script only adds to LD_LIBRARY_PATH if the appropriate path isn't > already there - changing this to always setup LD_LIBRARY_PATH from > scratch causes the binary to run as expected. Yes, Valgrind adds an entry to the start of LD_LIBRARY_PATH, and then blanks it out for any child processes. This leaves a big hole in the result, as above. A similar thing is done with LD_PRELOAD. I thought this (having blanks present) was acceptable, but maybe not? I can fix it if it's incorrect. N |
|
From: Lee K. <lki...@cs...> - 2003-07-21 10:05:35
|
Nicholas Nethercote writes: > On Mon, 21 Jul 2003, Lee Kindness wrote: > > Guys, have been seeing so real wiredness with VG 1.9.6 and in the > > recently released snapshot. > > > > *** env.sorted 2003-07-21 10:42:25.000000000 +0100 > > --- env-vg.sorted 2003-07-21 10:42:11.000000000 +0100 > > *************** > > *** 8,14 **** > > ! LD_LIBRARY_PATH=/home/lofs/lofs_1.1.4-20030721a/lib: > > --- 8,16 ---- > > ! LD_LIBRARY_PATH= /home/lofs/lofs_1.1.4-20030721a/lib: > > *************** > > *** 23,32 **** > > > > Note the spaces before LD_LIBRARY_PATH - this is causing the libraries > > to be missed! Something up with the "mashing" that is done? Currently > > the script only adds to LD_LIBRARY_PATH if the appropriate path isn't > > already there - changing this to always setup LD_LIBRARY_PATH from > > scratch causes the binary to run as expected. > > Yes, Valgrind adds an entry to the start of LD_LIBRARY_PATH, and then > blanks it out for any child processes. This leaves a big hole in the > result, as above. A similar thing is done with LD_PRELOAD. > > I thought this (having blanks present) was acceptable, but maybe not? I > can fix it if it's incorrect. No, the blanks kill the library search mechanism - it's looking for the paths exactly as specified, including the leading whitespace. If you leave the ':' separator in when mashing, ie: LD_LIBRARY_PATH would be: LD_LIBRARY_PATH= :/home/lofs/lofs_1.1.4-20030721a/lib: then everything is fine since the whitespace is tacked onto a valid path, but rather is "on its own". I'm guessing though that this behaviour may be a recent addition to glibc - i've certainly seen my program and valgrind work as expected before! Thanks for the quick response. L. |