|
From: Julian S. <js...@ac...> - 2005-08-19 16:52:54
|
> 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 110203 has already been fixed and will appear in 3.0.1. 110201 may get fixed for 3.0.1. 110205 is serious and investigations have already begun, but it is unclear how soon we can arrive at a fix. The rest are quite obscure and it is unlikely that they will affect more than a tiny number of users. If duplicates of them appear, then of course we will bump their priority. While we certainly appreciate advanced users who push Valgrind to the limit, like everyone else we have limited development resources and so we have to concentrate on making Valgrind work well for the 99% of the user base who are not "pushing the envelope". Sometimes that means that bugs get fixed in a different order than one might like. > I am glad to see progress in valgrind. I also expect better systemmatic > testing in the development process. It would be great to have a more thorough testing process. Since this is an open-source project, please feel free to enhance/extend the automatic test system and/or add more test cases. J |