blob: b9265d1de7be3acb49a82ebe7484310b96b4ced6 [file] [log] [blame]
sewardj90238792003-05-05 00:23:42 +00001
sewardj626fd892003-07-16 20:10:26 +00002Snapshot 20030716 (16 July 2003)
sewardj9d916ed2003-07-14 23:38:40 +00003~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4
sewardj626fd892003-07-16 20:10:26 +0000520030716 is a snapshot of our current CVS head (development) branch.
sewardj9d916ed2003-07-14 23:38:40 +00006This is the branch which will become valgrind-2.0. It contains
7significant enhancements over the 1.9.X branch.
8
9Despite this being a snapshot of the CVS head, it is believed to be
10quite stable -- at least as stable as 1.9.6 or 1.0.4, if not more so
11-- and therefore suitable for widespread use. Please let us know asap
12if it causes problems for you.
13
14Two reasons for releasing a snapshot now are:
15
16- It's been a while since 1.9.6, and this snapshot fixes
17 various problems that 1.9.6 has with threaded programs
18 on glibc-2.3.X based systems.
19
20- So as to make available improvements in the 2.0 line.
21
sewardj626fd892003-07-16 20:10:26 +000022Major changes in 20030716, as compared to 1.9.6:
sewardj9d916ed2003-07-14 23:38:40 +000023
24- More fixes to threading support on glibc-2.3.1 and 2.3.2-based
25 systems (SuSE 8.2, Red Hat 9). If you have had problems
26 with inconsistent/illogical behaviour of errno, h_errno or the DNS
sewardj626fd892003-07-16 20:10:26 +000027 resolver functions in threaded programs, 20030716 should improve
sewardj9d916ed2003-07-14 23:38:40 +000028 matters. This snapshot seems stable enough to run OpenOffice.org
29 1.1rc on Red Hat 7.3, SuSE 8.2 and Red Hat 9, and that's a big
30 threaded app if ever I saw one.
31
32- Automatic generation of suppression records; you no longer
33 need to write them by hand. Use --gen-suppressions=yes.
34
sewardj21511802003-07-22 17:47:42 +000035- strcpy/memcpy/etc check their arguments for overlaps, when
36 running with the Memcheck or Addrcheck skins.
37
38- malloc_usable_size() is now supported.
39
40- new client requests:
41 - VALGRIND_COUNT_ERRORS, VALGRIND_COUNT_LEAKS:
42 useful with regression testing
43 - VALGRIND_NON_SIMD_CALL[0123]: for running arbitrary functions
44 on real CPU (use with caution!)
45
sewardj9d916ed2003-07-14 23:38:40 +000046- The GDB attach mechanism is more flexible. Allow the GDB to
47 be run to be specified by --gdb-path=/path/to/gdb, and specify
48 which file descriptor V will read its input from with
49 --input-fd=<number>.
50
sewardj21511802003-07-22 17:47:42 +000051- Cachegrind gives more accurate results (wasn't tracking instructions in
52 malloc() and friends previously, is now).
53
sewardj9d916ed2003-07-14 23:38:40 +000054- Complete support for the MMX instruction set.
55
56- Partial support for the SSE and SSE2 instruction sets. Work for this
57 is ongoing. About half the SSE/SSE2 instructions are done, so
58 some SSE based programs may work. Currently you need to specify
59 --skin=addrcheck. Basically not suitable for real use yet.
60
61- Significant speedups (10%-20%) for standard memory checking.
62
63- Fix assertion failure in pthread_once().
64
65- Fix this:
66 valgrind: vg_intercept.c:598 (vgAllRoadsLeadToRome_select):
67 Assertion `ms_end >= ms_now' failed.
68
69- Implement pthread_mutexattr_setpshared.
70
71- Understand Pentium 4 branch hints. Also implemented a couple more
72 obscure x86 instructions.
73
74- Lots of other minor bug fixes.
75
sewardj626fd892003-07-16 20:10:26 +000076- We have a decent regression test system, for the first time.
77 This doesn't help you directly, but it does make it a lot easier
78 for us to track the quality of the system, especially across
79 multiple linux distributions.
80
81 You can run the regression tests with 'make regtest' after 'make
82 install' completes. On SuSE 8.2 and Red Hat 9 I get this:
83
84 == 84 tests, 0 stderr failures, 0 stdout failures ==
85
86 On Red Hat 8, I get this:
87
88 == 84 tests, 2 stderr failures, 1 stdout failure ==
89 corecheck/tests/res_search (stdout)
90 memcheck/tests/sigaltstack (stderr)
91
92 sigaltstack is probably harmless. res_search doesn't work
93 on R H 8 even running natively, so I'm not too worried.
94
95 On Red Hat 7.3, a glibc-2.2.5 system, I get these harmless failures:
96
97 == 84 tests, 2 stderr failures, 1 stdout failure ==
98 corecheck/tests/pth_atfork1 (stdout)
99 corecheck/tests/pth_atfork1 (stderr)
100 memcheck/tests/sigaltstack (stderr)
101
102 You need to run on a PII system, at least, since some tests
103 contain P6-specific instructions, and the test machine needs
104 access to the internet so that corecheck/tests/res_search
105 (a test that the DNS resolver works) can function.
106
sewardj9d916ed2003-07-14 23:38:40 +0000107As ever, thanks for the vast amount of feedback :) and bug reports :(
108We may not answer all messages, but we do at least look at all of
109them, and tend to fix the most frequently reported bugs.
110
111
112
sewardj37918822003-05-05 01:05:09 +0000113Version 1.9.6 (7 May 2003 or thereabouts)
114~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
115
116Major changes in 1.9.6:
117
118- Improved threading support for glibc >= 2.3.2 (SuSE 8.2,
119 RedHat 9, to name but two ...) It turned out that 1.9.5
120 had problems with threading support on glibc >= 2.3.2,
121 usually manifested by threaded programs deadlocking in system calls,
122 or running unbelievably slowly. Hopefully these are fixed now. 1.9.6
123 is the first valgrind which gives reasonable support for
124 glibc-2.3.2. Also fixed a 2.3.2 problem with pthread_atfork().
125
126- Majorly expanded FAQ.txt. We've added workarounds for all
127 common problems for which a workaround is known.
128
129Minor changes in 1.9.6:
130
131- Fix identification of the main thread's stack. Incorrect
132 identification of it was causing some on-stack addresses to not get
133 identified as such. This only affected the usefulness of some error
134 messages; the correctness of the checks made is unchanged.
135
136- Support for kernels >= 2.5.68.
137
138- Dummy implementations of __libc_current_sigrtmin,
139 __libc_current_sigrtmax and __libc_allocate_rtsig, hopefully
140 good enough to keep alive programs which previously died for lack of
141 them.
142
143- Fix bug in the VALGRIND_DISCARD_TRANSLATIONS client request.
144
sewardj3d47b792003-05-05 22:15:35 +0000145- Fix bug in the DWARF2 debug line info loader, when instructions
146 following each other have source lines far from each other
147 (e.g. with inlined functions).
148
sewardj37918822003-05-05 01:05:09 +0000149- Debug info reading: read symbols from both "symtab" and "dynsym"
150 sections, rather than merely from the one that comes last in the
151 file.
152
153- New syscall support: prctl(), creat(), lookup_dcookie().
154
155- When checking calls to accept(), recvfrom(), getsocketopt(),
156 don't complain if buffer values are NULL.
157
158- Try and avoid assertion failures in
159 mash_LD_PRELOAD_and_LD_LIBRARY_PATH.
160
161- Minor bug fixes in cg_annotate.
162
163
164
sewardj90238792003-05-05 00:23:42 +0000165Version 1.9.5 (7 April 2003)
166~~~~~~~~~~~~~~~~~~~~~~~~~~~~
167
168It occurs to me that it would be helpful for valgrind users to record
169in the source distribution the changes in each release. So I now
170attempt to mend my errant ways :-) Changes in this and future releases
171will be documented in the NEWS file in the source distribution.
172
173Major changes in 1.9.5:
174
175- (Critical bug fix): Fix a bug in the FPU simulation. This was
176 causing some floating point conditional tests not to work right.
177 Several people reported this. If you had floating point code which
178 didn't work right on 1.9.1 to 1.9.4, it's worth trying 1.9.5.
179
180- Partial support for Red Hat 9. RH9 uses the new Native Posix
181 Threads Library (NPTL), instead of the older LinuxThreads.
182 This potentially causes problems with V which will take some
183 time to correct. In the meantime we have partially worked around
184 this, and so 1.9.5 works on RH9. Threaded programs still work,
185 but they may deadlock, because some system calls (accept, read,
186 write, etc) which should be nonblocking, in fact do block. This
187 is a known bug which we are looking into.
188
189 If you can, your best bet (unfortunately) is to avoid using
190 1.9.5 on a Red Hat 9 system, or on any NPTL-based distribution.
191 If your glibc is 2.3.1 or earlier, you're almost certainly OK.
192
193Minor changes in 1.9.5:
194
195- Added some #errors to valgrind.h to ensure people don't include
196 it accidentally in their sources. This is a change from 1.0.X
197 which was never properly documented. The right thing to include
198 is now memcheck.h. Some people reported problems and strange
199 behaviour when (incorrectly) including valgrind.h in code with
200 1.9.1 -- 1.9.4. This is no longer possible.
201
202- Add some __extension__ bits and pieces so that gcc configured
203 for valgrind-checking compiles even with -Werror. If you
204 don't understand this, ignore it. Of interest to gcc developers
205 only.
206
207- Removed a pointless check which caused problems interworking
208 with Clearcase. V would complain about shared objects whose
209 names did not end ".so", and refuse to run. This is now fixed.
210 In fact it was fixed in 1.9.4 but not documented.
211
212- Fixed a bug causing an assertion failure of "waiters == 1"
213 somewhere in vg_scheduler.c, when running large threaded apps,
214 notably MySQL.
215
216- Add support for the munlock system call (124).
217
218Some comments about future releases:
219
2201.9.5 is, we hope, the most stable Valgrind so far. It pretty much
221supersedes the 1.0.X branch. If you are a valgrind packager, please
222consider making 1.9.5 available to your users. You can regard the
2231.0.X branch as obsolete: 1.9.5 is stable and vastly superior. There
224are no plans at all for further releases of the 1.0.X branch.
225
226If you want a leading-edge valgrind, consider building the cvs head
227(from SourceForge), or getting a snapshot of it. Current cool stuff
228going in includes MMX support (done); SSE/SSE2 support (in progress),
229a significant (10-20%) performance improvement (done), and the usual
230large collection of minor changes. Hopefully we will be able to
231improve our NPTL support, but no promises.
232