|
From: Julian S. <js...@ac...> - 2003-12-14 18:23:53
|
2.1.0 is available at the usual place, http://valgrind.kde.org. J Unstable (cvs head) release 2.1.0 (15 December 2003) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For whatever it's worth, 2.1.0 actually seems pretty darn stable to me (Julian). It looks eminently usable, and given that it fixes some significant bugs, may well be worth using on a day-to-day basis. 2.1.0 is known to build and pass regression tests on: SuSE 9, SuSE 8.2, RedHat 8. 2.1.0 most notably includes Jeremy Fitzhardinge's complete overhaul of handling of system calls and signals, and their interaction with threads. In general, the accuracy of the system call, thread and signal simulations is much improved. Specifically: - Blocking system calls behave exactly as they do when running natively (not on valgrind). That is, if a syscall blocks only the calling thread when running natively, than it behaves the same on valgrind. No more mysterious hangs because V doesn't know that some syscall or other, should block only the calling thread. - Interrupted syscalls should now give more faithful results. - Finally, signal contexts in signal handlers are supported. As a result, konqueror on SuSE 9 no longer segfaults when notified of file changes in directories it is watching. Other changes: - Robert Walsh's file descriptor leakage checks. When enabled, Valgrind will print out a list of open file descriptors on exit. Along with each file descriptor, Valgrind prints out a stack backtrace of where the file was opened and any details relating to the file descriptor such as the file name or socket details. To use, give: --track-fds=yes - Implemented a few more SSE/SSE2 instructions. - Less crud on the stack when you do 'where' inside a GDB attach. - Fixed the following bugs: 68360: Valgrind does not compile against 2.6.0-testX kernels 68525: CVS head doesn't compile on C90 compilers 68566: pkgconfig support (wishlist) 68588: Assertion `sz == 4' failed in vg_to_ucode.c (disInstr) 69140: valgrind not able to explicitly specify a path to a binary. 69432: helgrind asserts encountering a MutexErr when there are EraserErr suppressions - Increase the max size of the translation cache from 200k average bbs to 300k average bbs. Programs on the size of OOo (680m17) are thrashing the cache at the smaller size, creating large numbers of retranslations and wasting significant time as a result. |
|
From: Crispin F. <val...@fl...> - 2003-12-15 14:25:30
|
> 2.1.0 is known to build and pass regression tests on: SuSE 9, SuSE > 8.2, RedHat 8. I just thought I would mention, that on Debian Sid, it build and runs fine, but fails a few of the regression tests: == 108 tests, 8 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) Apart from the inherit failure (which looks like a known failure??), these are all of the form (obviously with different system calls) *************** *** 2 **** ! at 0x........: __ioctl (in /...libc...) --- 2 ---- ! at 0x........: ioctl (in /...libc...) Crispin |
|
From: Jim M. <ji...@me...> - 2003-12-15 14:30:16
|
Julian Seward <js...@ac...> wrote: > 2.1.0 is available at the usual place, http://valgrind.kde.org. I discovered a small problem in that some error output from valgrind went to stdout. Unfortunately, I'd redirected stdout for the program being operated on and didn't see valgrind's message about ``./foo not found in $PATH, aborting''. In addition, valgrind exited successfully even though it didn't find or run the specified program, so I assumed it had succeeded. The exit status of 127 is pretty commonly used for cases like this. For example, GNU nice and nohup both exit with status 127 if their attempt to exec the specified file fails due to ENOENT. However, I've just noticed that there are numerous other places where diagnostics are `echo'ed to stdout rather than stderr. Perhaps they should be changed, too. Here's a patch that changes only the exit status: --- coregrind/valgrind.in.~1~ 2003-12-15 15:10:09.000000000 +0100 +++ coregrind/valgrind.in 2003-12-15 15:24:38.000000000 +0100 @@ -115,7 +115,7 @@ if [ $# != 0 ] ; then if [ z$which_prog = z ]; then echo "$0: '$1' not found in \$PATH, aborting." - exit + exit 127 fi if [ $# != 0 ] ; then If you'd also like to redirect all diagnostics to stdout, then here's a combined patch that does that, too: --- coregrind/valgrind.in.~1~ 2003-12-15 15:10:09.000000000 +0100 +++ coregrind/valgrind.in 2003-12-15 15:27:19.000000000 +0100 @@ -79,12 +79,12 @@ fi # Setup tool shared object. tool_so="vgskin_${tool}.so" if [ ! -r "$tooldir/$tool_so" ] ; then - echo - echo "Tool error:" - echo " The shared library \`$tool_so' for the chosen" - echo " tool \`$tool' could not be found in" - echo " $tooldir" - echo + echo >&2 + echo "Tool error:" >&2 + echo " The shared library \`$tool_so' for the chosen" >&2 + echo " tool \`$tool' could not be found in" >&2 + echo " $tooldir" >&2 + echo >&2 exit 1 fi @@ -114,27 +114,27 @@ if [ $# != 0 ] ; then fi if [ z$which_prog = z ]; then - echo "$0: '$1' not found in \$PATH, aborting." - exit + echo "$0: '$1' not found in \$PATH, aborting." >&2 + exit 127 fi if [ $# != 0 ] ; then case `file -L "$which_prog"` in # must follow symlinks, hence -L # Ensure the program isn't statically linked. *"statically linked"*) - echo "\`$which_prog' is statically linked" - echo "Valgrind only works on dynamically linked executables; your" - echo "program must rely on at least one shared object for Valgrind" - echo "to work with it. Read FAQ #5 for more information." + echo "\`$which_prog' is statically linked" >&2 + echo "Valgrind only works on dynamically linked executables; your" >&2 + echo "program must rely on at least one shared object for Valgrind" >&2 + echo "to work with it. Read FAQ #5 for more information." >&2 exit 1 ;; # Ensure that there are no setuid or gid flags *:\ set?id\ ELF*) - echo "\`$which_prog' is suid/sgid." - echo "Valgrind can't handle these executables, as it" - echo "requires the LD_PRELOAD feature in order to work." - echo "" - echo "Remove those flags and try again." - echo "" + echo "\`$which_prog' is suid/sgid." >&2 + echo "Valgrind can't handle these executables, as it" >&2 + echo "requires the LD_PRELOAD feature in order to work." >&2 + echo "" >&2 + echo "Remove those flags and try again." >&2 + echo "" >&2 exit 1 ;; esac |
|
From: Jeremy F. <je...@go...> - 2003-12-15 17:59:57
|
On Mon, 2003-12-15 at 06:21, Crispin Flowerday wrote: > Apart from the inherit failure (which looks like a known failure??), > these are all of the form (obviously with different system calls) > > *************** > *** 2 **** > ! at 0x........: __ioctl (in /...libc...) > --- 2 ---- > ! at 0x........: ioctl (in /...libc...) I just checked in a fix to canonicalize these aliased symbols so that the plain form "ioctl" is preferred over "__ioctl", "__libc_ioctl", etc, even though the general policy is to prefer the longer name. I hope this will make error reports a bit more consistent over different versions of glibc. J |
|
From: <ar...@de...> - 2003-12-15 18:17:36
|
Jeremy Fitzhardinge <je...@go...> writes: > On Mon, 2003-12-15 at 06:21, Crispin Flowerday wrote: >> Apart from the inherit failure (which looks like a known failure??), >> these are all of the form (obviously with different system calls) >> >> *************** >> *** 2 **** >> ! at 0x........: __ioctl (in /...libc...) >> --- 2 ---- >> ! at 0x........: ioctl (in /...libc...) > > I just checked in a fix to canonicalize these aliased symbols so that > the plain form "ioctl" is preferred over "__ioctl", "__libc_ioctl", etc, > even though the general policy is to prefer the longer name. > > I hope this will make error reports a bit more consistent over different > versions of glibc. Can you post the patch? :) > > J > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Andres Roldan Fluidsignal Group <ar...@fl...> The Debian Project <ar...@de...> GIGAX <ar...@gi...> GPG Key-ID 0xB29396EB Home Page http://people.fluidsignal.com/~aroldan |