|
From: Julian S. <js...@ac...> - 2004-08-31 16:36:55
|
We are pleased to announce a new stable release, valgrind-2.2.0. It is available from the usual place: http://valgrind.kde.org. Happy debugging and profiling -- The Valgrind developers Stable release 2.2.0 (31 August 2004) -- CHANGES RELATIVE TO 2.0.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2.2.0 brings nine months worth of improvements and bug fixes. We believe it to be a worthy successor to 2.0.0. There are literally hundreds of bug fixes and minor improvements. There are also some fairly major user-visible changes: * A 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: - 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. - Signal contexts in signal handlers are supported. * Improvements to NPTL support to the extent that V now works properly on NPTL-only setups. * Greater isolation between Valgrind and the program being run, so the program is less likely to inadvertently kill Valgrind by doing wild writes. * Massif: a new space profiling tool. Try it! It's cool, and it'll tell you in detail where and when your C/C++ code is allocating heap. Draws pretty .ps pictures of memory use against time. A potentially powerful tool for making sense of your program's space use. * File descriptor leakage checks. When enabled, Valgrind will print out a list of open file descriptors on exit. * Improved SSE2/SSE3 support. * Time-stamped output; use --time-stamp=yes Stable release 2.2.0 (31 August 2004) -- CHANGES RELATIVE TO 2.1.2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2.2.0 is not much different from 2.1.2, released seven weeks ago. A number of bugs have been fixed, most notably #85658, which gave problems for quite a few people. There have been many internal cleanups, but those are not user visible. The following bugs have been fixed since 2.1.2: 85658 Assert in coregrind/vg_libpthread.c:2326 (open64) != (void*)0 failed This bug was reported multiple times, and so the following duplicates of it are also fixed: 87620, 85796, 85935, 86065, 86919, 86988, 87917, 88156 80716 Semaphore mapping bug caused by unmap (sem_destroy) (Was fixed prior to 2.1.2) 86987 semctl and shmctl syscalls family is not handled properly 86696 valgrind 2.1.2 + RH AS2.1 + librt 86730 valgrind locks up at end of run with assertion failure in __pthread_unwind 86641 memcheck doesn't work with Mesa OpenGL/ATI on Suse 9.1 (also fixes 74298, a duplicate of this) 85947 MMX/SSE unhandled instruction 'sfence' 84978 Wrong error "Conditional jump or move depends on uninitialised value" resulting from "sbbl %reg, %reg" 86254 ssort() fails when signed int return type from comparison is too small to handle result of unsigned int subtraction 87089 memalign( 4, xxx) makes valgrind assert 86407 Add support for low-level parallel port driver ioctls. 70587 Add timestamps to Valgrind output? (wishlist) 84937 vg_libpthread.c:2505 (se_remap): Assertion `res == 0' (fixed prior to 2.1.2) 86317 cannot load libSDL-1.2.so.0 using valgrind 86989 memcpy from mac_replace_strmem.c complains about uninitialized pointers passed when length to copy is zero 85811 gnu pascal symbol causes segmentation fault; ok in 2.0.0 79138 writing to sbrk()'d memory causes segfault 77369 sched deadlock while signal received during pthread_join and the joined thread exited 88115 In signal handler for SIGFPE, siginfo->si_addr is wrong under Valgrind 78765 Massif crashes on app exit if FP exceptions are enabled Additionally there are the following changes, which are not connected to any bug report numbers, AFAICS: * Fix scary bug causing mis-identification of SSE stores vs loads and so causing memcheck to sometimes give nonsense results on SSE code. * Add support for the POSIX message queue system calls. * Fix to allow 32-bit Valgrind to run on AMD64 boxes. Note: this does NOT allow Valgrind to work with 64-bit executables - only with 32-bit executables on an AMD64 box. * At configure time, only check whether linux/mii.h can be processed so that we don't generate ugly warnings by trying to compile it. * Add support for POSIX clocks and timers. |
|
From: Alex I. <ale...@in...> - 2004-09-07 21:19:30
|
With valgrind 2.2.0, why am I getting swamped with "@@ unlikely looking definition in unparsed reamins ";"" messages when loading shared libraries? What are the implications of these warnings? Alex Julian Seward wrote: >We are pleased to announce a new stable release, valgrind-2.2.0. >It is available from the usual place: http://valgrind.kde.org. > >Happy debugging and profiling > >-- The Valgrind developers > > > >Stable release 2.2.0 (31 August 2004) -- CHANGES RELATIVE TO 2.0.0 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >2.2.0 brings nine months worth of improvements and bug fixes. We >believe it to be a worthy successor to 2.0.0. There are literally >hundreds of bug fixes and minor improvements. There are also some >fairly major user-visible changes: > >* A 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: > > - 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. > > - Signal contexts in signal handlers are supported. > >* Improvements to NPTL support to the extent that V now works > properly on NPTL-only setups. > >* Greater isolation between Valgrind and the program being run, so > the program is less likely to inadvertently kill Valgrind by > doing wild writes. > >* Massif: a new space profiling tool. Try it! It's cool, and it'll > tell you in detail where and when your C/C++ code is allocating heap. > Draws pretty .ps pictures of memory use against time. A potentially > powerful tool for making sense of your program's space use. > >* File descriptor leakage checks. When enabled, Valgrind will print out > a list of open file descriptors on exit. > >* Improved SSE2/SSE3 support. > >* Time-stamped output; use --time-stamp=yes > > >Stable release 2.2.0 (31 August 2004) -- CHANGES RELATIVE TO 2.1.2 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >2.2.0 is not much different from 2.1.2, released seven weeks ago. >A number of bugs have been fixed, most notably #85658, which gave >problems for quite a few people. There have been many internal >cleanups, but those are not user visible. > >The following bugs have been fixed since 2.1.2: > >85658 Assert in coregrind/vg_libpthread.c:2326 (open64) != > (void*)0 failed > This bug was reported multiple times, and so the following > duplicates of it are also fixed: 87620, 85796, 85935, 86065, > 86919, 86988, 87917, 88156 > >80716 Semaphore mapping bug caused by unmap (sem_destroy) > (Was fixed prior to 2.1.2) > >86987 semctl and shmctl syscalls family is not handled properly > >86696 valgrind 2.1.2 + RH AS2.1 + librt > >86730 valgrind locks up at end of run with assertion failure > in __pthread_unwind > >86641 memcheck doesn't work with Mesa OpenGL/ATI on Suse 9.1 > (also fixes 74298, a duplicate of this) > >85947 MMX/SSE unhandled instruction 'sfence' > >84978 Wrong error "Conditional jump or move depends on > uninitialised value" resulting from "sbbl %reg, %reg" > >86254 ssort() fails when signed int return type from comparison is > too small to handle result of unsigned int subtraction > >87089 memalign( 4, xxx) makes valgrind assert > >86407 Add support for low-level parallel port driver ioctls. > >70587 Add timestamps to Valgrind output? (wishlist) > >84937 vg_libpthread.c:2505 (se_remap): Assertion `res == 0' > (fixed prior to 2.1.2) > >86317 cannot load libSDL-1.2.so.0 using valgrind > >86989 memcpy from mac_replace_strmem.c complains about > uninitialized pointers passed when length to copy is zero > >85811 gnu pascal symbol causes segmentation fault; ok in 2.0.0 > >79138 writing to sbrk()'d memory causes segfault > >77369 sched deadlock while signal received during pthread_join > and the joined thread exited > >88115 In signal handler for SIGFPE, siginfo->si_addr is wrong > under Valgrind > >78765 Massif crashes on app exit if FP exceptions are enabled > >Additionally there are the following changes, which are not >connected to any bug report numbers, AFAICS: > >* Fix scary bug causing mis-identification of SSE stores vs > loads and so causing memcheck to sometimes give nonsense results > on SSE code. > >* Add support for the POSIX message queue system calls. > >* Fix to allow 32-bit Valgrind to run on AMD64 boxes. Note: this does > NOT allow Valgrind to work with 64-bit executables - only with 32-bit > executables on an AMD64 box. > >* At configure time, only check whether linux/mii.h can be processed > so that we don't generate ugly warnings by trying to compile it. > >* Add support for POSIX clocks and timers. > > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click >_______________________________________________ >Valgrind-users mailing list >Val...@li... >https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Inet Technologies, Inc. ------------------------------------------------------------------------ |