|
From: Nicholas N. <nj...@cs...> - 2005-03-09 01:01:06
|
On Tue, 8 Mar 2005, Jeremy Fitzhardinge wrote: > I've made a test release of 2.4.0-rc1 and put it at > http://www.goop.org/~jeremy/valgrind/dist. I've included the source > tar, the source RPM and an FC3 i386 binary RPM. > > This is identical to CVS HEAD except for the version number. > > Please try it out. If it looks good, I think we should ship it. My machine: Debian 3.0. Linux charco.cs.utexas.edu 2.4.29 #1 SMP Mon Jan 24 09:20:36 CST 2005 i686 unknown GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. ---- I'm getting the following regtest failures: == 198 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/manuel2 (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/zeropage (stdout) corecheck/tests/fdleak_creat (stderr) leak-tree, manuel2, pth_once, threadederrno and vgtest_ume I've been getting for a while, and I'm not very worried about them. fdleak_creat is new. The diff is: ! at 0x........: creat (in /...libc...) ! by 0x........: __libc_start_main (in /...libc...) ! by 0x........: ... --- 6,7 ---- ! at 0x........: open (in /...libc...) ! by 0x........: main (fdleak_creat.c:18) ie. it looks like something has changed on my system so that libc's creat() no calls open(). So probably not a problem. The zeropage one I've not seen before. Valgrind used to prevent clients from doing an mmap(FIXED) in the bottom 64KB of memory. Jeremy, you changed VG_(valid_client_addr)() on January 15 (rev 1.229) to disable this. The commit log said: Misc changes needed so that Valgrind can run itself. I'm not sure if this was a good thing to do -- IIRC I original put that restriction in because some of the memory allocation functions use 0 to represent failure, and so if a program did mmap(0x0, FIXED) various problems could occur. I don't know why this test has been succeeding since Jan 15, only to fail now. Another problem... this program: int main(void) { read(0,0,1); } behaves differently under Valgrind compared to native -- it doesn't wait for user input. The problem also arises from January 15, when you changed almost every use of the PRE_MEM_WRITE macro to your new SYS_PRE_MEM_WRITE macro. Did you write these new macros to address a particular problem? I don't like like this macro, because it assumes that any unaddressable argument causes the syscall to fail, which is not necessarily the case. And I'm not keen on the obvious fix -- change sys_read to use PRE_MEM_WRITE -- because I imagine that this non-failure-on-unaddressable-memory behaviour is possible on any number of the syscalls. N |