|
From: John R.
|
> We did put out a release candidate which you could have tried if you > had wanted, and we plan to release a 3.0.1 fairly soon to address some > of the issues (including those you have raised) in the 3.0.0 release. I did try the release candidate 3.0 SVN as of 2005-07-27. In fact, I was ambitious enough to attempt running all the glibc internal testcases under memcheck. Alas, failure: http://bugs.kde.org/show_bug.cgi?id=109744 "memcheck loses track of mmap from direct ld-linux.so.2". This was a showstopper for a while. When the 3.0 release appeared just a few days later at the beginning of August, I isolated the cause: http://bugs.kde.org/show_bug.cgi?id=110183 "tail of page with _end[] is initialized, but not for memcheck". I modified glibc to avoid the problem, which lead to more reports: 110201 x86 'fxtract' opcode unhandled 110202 x86 'waitpid' syscall unhandled 110203 clock_getres(,0) does not store to 0 110204 strlen from fmemopen 110205 sigcancel_handler fails 110207 wrong answers from mpn ## user error [but ...] 110208 wrong answer for failing execve 110209 --show-emwarns vs default floating point fixups I am glad to see progress in valgrind. I also expect better systemmatic testing in the development process. -- |