Re: [Valgrind-users] valgrind-2.2.0 is available

[Alex I. <ale...@in...>]

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.
------------------------------------------------------------------------