From 43d9adea1d53981e90eb4961750cb98c2d01820d Mon Sep 17 00:00:00 2001 From: Julian Seward Date: Fri, 12 Mar 2004 21:07:05 +0000 Subject: [PATCH] Update for 2.1.1. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2309 --- NEWS | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) diff --git a/NEWS b/NEWS index 855e29881..32c09149c 100644 --- a/NEWS +++ b/NEWS @@ -1,4 +1,81 @@ +Unstable (cvs head) release 2.1.1 (12 March 2004) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +2.1.1 contains some internal structure changes needed for V's +long-term future. These don't affect end-users. Most notable +user-visible changes are: + +* 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. + +* Fixes for many bugs, including support for more SSE2/SSE3 instructions, + various signal/syscall things, and various problems with debug + info readers. + +* Support for glibc-2.3.3 based systems. + +We are now doing automatic overnight build-and-test runs on a variety +of distros. As a result, we believe 2.1.1 builds and runs on: +Red Hat 7.2, 7.3, 8.0, 9, Fedora Core 1, SuSE 8.2, SuSE 9. + + +The following bugs, and probably many more, have been fixed. These +are listed at http://bugs.kde.org. Reporting a bug for valgrind in +the http://bugs.kde.org is much more likely to get you a fix than +mailing developers directly, so please continue to keep sending bugs +there. + +69616 glibc 2.3.2 w/NPTL is massively different than what valgrind expects +69856 I don't know how to instrument MMXish stuff (Helgrind) +73892 valgrind segfaults starting with Objective-C debug info + (fix for S-type stabs) +73145 Valgrind complains too much about close() +73902 Shadow memory allocation seems to fail on RedHat 8.0 +68633 VG_N_SEMAPHORES too low (V itself was leaking semaphores) +75099 impossible to trace multiprocess programs +76839 the `impossible' happened: disInstr: INT but not 0x80 ! +76762 vg_to_ucode.c:3748 (dis_push_segreg): Assertion `sz == 4' failed. +76747 cannot include valgrind.h in c++ program +76223 parsing B(3,10) gave NULL type => impossible happens +75604 shmdt handling problem +76416 Problems with gcc 3.4 snap 20040225 +75614 using -gstabs when building your programs the `impossible' happened +75787 Patch for some CDROM ioctls CDORM_GET_MCN, CDROM_SEND_PACKET, +75294 gcc 3.4 snapshot's libstdc++ have unsupported instructions. + (REP RET) +73326 vg_symtab2.c:272 (addScopeRange): Assertion `range->size > 0' failed. +72596 not recognizing __libc_malloc +69489 Would like to attach ddd to running program +72781 Cachegrind crashes with kde programs +73055 Illegal operand at DXTCV11CompressBlockSSE2 (more SSE opcodes) +73026 Descriptor leak check reports port numbers wrongly +71705 README_MISSING_SYSCALL_OR_IOCTL out of date +72643 Improve support for SSE/SSE2 instructions +72484 valgrind leaves it's own signal mask in place when execing +72650 Signal Handling always seems to restart system calls +72006 The mmap system call turns all errors in ENOMEM +71781 gdb attach is pretty useless +71180 unhandled instruction bytes: 0xF 0xAE 0x85 0xE8 +69886 writes to zero page cause valgrind to assert on exit +71791 crash when valgrinding gimp 1.3 (stabs reader problem) +69783 unhandled syscall: 218 +69782 unhandled instruction bytes: 0x66 0xF 0x2B 0x80 +70385 valgrind fails if the soft file descriptor limit is less + than about 828 +69529 "rep; nop" should do a yield +70827 programs with lots of shared libraries report "mmap failed" + for some of them when reading symbols +71028 glibc's strnlen is optimised enough to confuse valgrind + + + + 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