sewardj | 9023879 | 2003-05-05 00:23:42 +0000 | [diff] [blame] | 1 | |
sewardj | 3791882 | 2003-05-05 01:05:09 +0000 | [diff] [blame] | 2 | Version 1.9.6 (7 May 2003 or thereabouts) |
| 3 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 4 | |
| 5 | Major changes in 1.9.6: |
| 6 | |
| 7 | - Improved threading support for glibc >= 2.3.2 (SuSE 8.2, |
| 8 | RedHat 9, to name but two ...) It turned out that 1.9.5 |
| 9 | had problems with threading support on glibc >= 2.3.2, |
| 10 | usually manifested by threaded programs deadlocking in system calls, |
| 11 | or running unbelievably slowly. Hopefully these are fixed now. 1.9.6 |
| 12 | is the first valgrind which gives reasonable support for |
| 13 | glibc-2.3.2. Also fixed a 2.3.2 problem with pthread_atfork(). |
| 14 | |
| 15 | - Majorly expanded FAQ.txt. We've added workarounds for all |
| 16 | common problems for which a workaround is known. |
| 17 | |
| 18 | Minor changes in 1.9.6: |
| 19 | |
| 20 | - Fix identification of the main thread's stack. Incorrect |
| 21 | identification of it was causing some on-stack addresses to not get |
| 22 | identified as such. This only affected the usefulness of some error |
| 23 | messages; the correctness of the checks made is unchanged. |
| 24 | |
| 25 | - Support for kernels >= 2.5.68. |
| 26 | |
| 27 | - Dummy implementations of __libc_current_sigrtmin, |
| 28 | __libc_current_sigrtmax and __libc_allocate_rtsig, hopefully |
| 29 | good enough to keep alive programs which previously died for lack of |
| 30 | them. |
| 31 | |
| 32 | - Fix bug in the VALGRIND_DISCARD_TRANSLATIONS client request. |
| 33 | |
sewardj | 3d47b79 | 2003-05-05 22:15:35 +0000 | [diff] [blame] | 34 | - Fix bug in the DWARF2 debug line info loader, when instructions |
| 35 | following each other have source lines far from each other |
| 36 | (e.g. with inlined functions). |
| 37 | |
sewardj | 3791882 | 2003-05-05 01:05:09 +0000 | [diff] [blame] | 38 | - Debug info reading: read symbols from both "symtab" and "dynsym" |
| 39 | sections, rather than merely from the one that comes last in the |
| 40 | file. |
| 41 | |
| 42 | - New syscall support: prctl(), creat(), lookup_dcookie(). |
| 43 | |
| 44 | - When checking calls to accept(), recvfrom(), getsocketopt(), |
| 45 | don't complain if buffer values are NULL. |
| 46 | |
| 47 | - Try and avoid assertion failures in |
| 48 | mash_LD_PRELOAD_and_LD_LIBRARY_PATH. |
| 49 | |
| 50 | - Minor bug fixes in cg_annotate. |
| 51 | |
| 52 | |
| 53 | |
sewardj | 9023879 | 2003-05-05 00:23:42 +0000 | [diff] [blame] | 54 | Version 1.9.5 (7 April 2003) |
| 55 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 56 | |
| 57 | It occurs to me that it would be helpful for valgrind users to record |
| 58 | in the source distribution the changes in each release. So I now |
| 59 | attempt to mend my errant ways :-) Changes in this and future releases |
| 60 | will be documented in the NEWS file in the source distribution. |
| 61 | |
| 62 | Major changes in 1.9.5: |
| 63 | |
| 64 | - (Critical bug fix): Fix a bug in the FPU simulation. This was |
| 65 | causing some floating point conditional tests not to work right. |
| 66 | Several people reported this. If you had floating point code which |
| 67 | didn't work right on 1.9.1 to 1.9.4, it's worth trying 1.9.5. |
| 68 | |
| 69 | - Partial support for Red Hat 9. RH9 uses the new Native Posix |
| 70 | Threads Library (NPTL), instead of the older LinuxThreads. |
| 71 | This potentially causes problems with V which will take some |
| 72 | time to correct. In the meantime we have partially worked around |
| 73 | this, and so 1.9.5 works on RH9. Threaded programs still work, |
| 74 | but they may deadlock, because some system calls (accept, read, |
| 75 | write, etc) which should be nonblocking, in fact do block. This |
| 76 | is a known bug which we are looking into. |
| 77 | |
| 78 | If you can, your best bet (unfortunately) is to avoid using |
| 79 | 1.9.5 on a Red Hat 9 system, or on any NPTL-based distribution. |
| 80 | If your glibc is 2.3.1 or earlier, you're almost certainly OK. |
| 81 | |
| 82 | Minor changes in 1.9.5: |
| 83 | |
| 84 | - Added some #errors to valgrind.h to ensure people don't include |
| 85 | it accidentally in their sources. This is a change from 1.0.X |
| 86 | which was never properly documented. The right thing to include |
| 87 | is now memcheck.h. Some people reported problems and strange |
| 88 | behaviour when (incorrectly) including valgrind.h in code with |
| 89 | 1.9.1 -- 1.9.4. This is no longer possible. |
| 90 | |
| 91 | - Add some __extension__ bits and pieces so that gcc configured |
| 92 | for valgrind-checking compiles even with -Werror. If you |
| 93 | don't understand this, ignore it. Of interest to gcc developers |
| 94 | only. |
| 95 | |
| 96 | - Removed a pointless check which caused problems interworking |
| 97 | with Clearcase. V would complain about shared objects whose |
| 98 | names did not end ".so", and refuse to run. This is now fixed. |
| 99 | In fact it was fixed in 1.9.4 but not documented. |
| 100 | |
| 101 | - Fixed a bug causing an assertion failure of "waiters == 1" |
| 102 | somewhere in vg_scheduler.c, when running large threaded apps, |
| 103 | notably MySQL. |
| 104 | |
| 105 | - Add support for the munlock system call (124). |
| 106 | |
| 107 | Some comments about future releases: |
| 108 | |
| 109 | 1.9.5 is, we hope, the most stable Valgrind so far. It pretty much |
| 110 | supersedes the 1.0.X branch. If you are a valgrind packager, please |
| 111 | consider making 1.9.5 available to your users. You can regard the |
| 112 | 1.0.X branch as obsolete: 1.9.5 is stable and vastly superior. There |
| 113 | are no plans at all for further releases of the 1.0.X branch. |
| 114 | |
| 115 | If you want a leading-edge valgrind, consider building the cvs head |
| 116 | (from SourceForge), or getting a snapshot of it. Current cool stuff |
| 117 | going in includes MMX support (done); SSE/SSE2 support (in progress), |
| 118 | a significant (10-20%) performance improvement (done), and the usual |
| 119 | large collection of minor changes. Hopefully we will be able to |
| 120 | improve our NPTL support, but no promises. |
| 121 | |