|
From: Nicholas N. <nj...@ca...> - 2004-02-29 00:22:40
|
On Sat, 28 Feb 2004, Tom Hughes wrote: > The one in helgrind/tests/inherit is down to it failing to print > the "XXX We expect an error on inherit.c:48" message but I can't > quite work out where that comes from anyway. To be honest I don't > think I've ever seen that test pass anywhere. That confused me too. The test is meant to fail, the message is a "fixme" that indicates what the expected output should be, ie. Helgrind should give an error but it doesn't. The right way to handle this is to have a way of marking a test as a known failure; that way we don't get reports about it failing, but it's clearly marked as doing the wrong thing. > The fdleak_ failures are caused by the overnight tests being run from > cron and getting /dev/null as standard input which is explicitly left > alone by the filter script and hence the output doesn't match the > expected results which are designed for running from a terminal where > the terminal name would get filtered out. I understood that paragraph up to "standard input", but the rest lost me. How is the filter script interacting with /dev/null? How does the terminal name get filtered out? Sorry if I'm being dense. > + valgrind's libpthread.so: init_libc_tsd_keys: lock > + Please report this bug at: valgrind.kde.org > > Which is a bit odd, because from looking at the code it means that > the attempt to lock the mutex in init_libc_tsd_keys is failing for > some reason. Hmm, I don't know about that one. > > There is also a new assertion firing in some tests: > > > > + valgrind: vg_libpthread.c:... (pthread_cond_init): Assertion `sizeof(*cond) >= > > sizeof(vg_pthread_cond_t)' failed. > > > > Presumably pthread_cond_t is a bit smaller in glibc 2.2 or something. > > Indeed. Having checked, it looks like the padding was only added > to pthread_cond_t in recent glibc's. I've commented out the padding and committed the change. I don't imagine it will break anything, since those padding fields are unused by Valgrind. > Virtually every test on RH7.3 is failing with a series of errors > like this: > > + warning: line info addresses out of order at entry 939: 0x........ 0x........ > + warning: line info addresses out of order at entry 943: 0x........ 0x........ We could remove such lines using the basic filter. Or not spit out the warning if it's not important. I think all the other problems could be handled by allowing multiple expected outputs, as Julian suggested. I'll look into changing the script. The only question is if you have multiple acceptable outputs, if none of them match, which do you use to form the .diff file? I figure it can give a .diff for every acceptable output, eg. .diff, .diff2, .diff3... N |