|
From: Tom H. <th...@cy...> - 2005-01-17 03:10:24
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-01-17 03:05:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow *** yield failed (stdout) *** -- Finished tests in none/tests ---------------------------------------- == 196 tests, 13 stderr failures, 1 stdout failure ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/yield (stdout) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2005-01-17 03:19:54
|
On Mon, 2005-01-17 at 03:10 +0000, Tom Hughes wrote: > memcheck/tests/pth_once (stderr) > memcheck/tests/scalar (stderr) > memcheck/tests/threadederrno (stderr) > memcheck/tests/vgtest_ume (stderr) What are these? > none/tests/yield (stdout) Can you think of any useful assertion this test could be making? Perhaps we should just kill it. J |
|
From: Tom H. <th...@cy...> - 2005-01-17 08:44:51
|
In message <1105931992.31917.42.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Mon, 2005-01-17 at 03:10 +0000, Tom Hughes wrote:
>> memcheck/tests/pth_once (stderr)
This is some warnings from pthread_create:
+ Syscall param write(buf) points to uninitialised byte(s)
+ at 0x........: write (in /...libc...)
+ by 0x........: pthread_create@@GLIBC_2.1 (in /lib/i686/libpthread-0.9.so)
+ by 0x........: main (pth_once.c:65)
+ Address 0x........ is on thread 1's stack
+
+ Syscall param write(buf) points to uninitialised byte(s)
+ at 0x........: write (in /...libc...)
+ by 0x........: main (pth_once.c:65)
+ Address 0x........ is on thread 1's stack
+
+ Syscall param write(buf) points to uninitialised byte(s)
+ at 0x........: write (in /...libc...)
+ by 0x........: main (pth_once.c:76)
+ Address 0x........ is on thread 1's stack
+
+ Syscall param write(buf) points to uninitialised byte(s)
+ at 0x........: write (in /...libc...)
+ by 0x........: exit (in /...libc...)
+ by 0x........: __libc_start_main (...libc...)
+ by 0x........: ...
+ Address 0x........ is on thread 1's stack
>> memcheck/tests/scalar (stderr)
This is asserting on the munlockall test:
-----------------------------------------------------
153: __NR_munlockall 0s 0m
-----------------------------------------------------
scalar: scalar.c:671: main: Assertion `-1 != res' failed.
>> memcheck/tests/threadederrno (stderr)
This is the same pthread_create warnings as the pth_once test.
>> memcheck/tests/vgtest_ume (stderr)
This is the usual _dl_relocate_object_internal problems but there
is no stack to match against the suppressions:
+ Conditional jump or move depends on uninitialised value(s)
+ at 0x........: _dl_relocate_object_internal (in /lib/ld-2.2.5.so)
+
+ Conditional jump or move depends on uninitialised value(s)
+ at 0x........: _dl_relocate_object_internal (in /lib/ld-2.2.5.so)
+
+ Conditional jump or move depends on uninitialised value(s)
+ at 0x........: _dl_relocate_object_internal (in /lib/ld-2.2.5.so)
+
+ Conditional jump or move depends on uninitialised value(s)
+ at 0x........: _dl_relocate_object_internal (in /lib/ld-2.2.5.so)
+
+ Conditional jump or move depends on uninitialised value(s)
+ at 0x........: _dl_relocate_object_internal (in /lib/ld-2.2.5.so)
>> none/tests/yield (stdout)
>
> Can you think of any useful assertion this test could be making?
> Perhaps we should just kill it.
Well what is it trying to test? Presumably the idea was to test that
the "rep; nop" sequence caused a yield properly.
Perhaps it is sufficient to test that "rep; nop" makes progress but
less progress that spinning?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2005-01-17 09:08:36
|
On Mon, 2005-01-17 at 08:44 +0000, Tom Hughes wrote: > In message <1105931992.31917.42.camel@localhost> > Jeremy Fitzhardinge <je...@go...> wrote: > > > On Mon, 2005-01-17 at 03:10 +0000, Tom Hughes wrote: > >> memcheck/tests/pth_once (stderr) > > This is some warnings from pthread_create: > > + Syscall param write(buf) points to uninitialised byte(s) > + at 0x........: write (in /...libc...) > + by 0x........: pthread_create@@GLIBC_2.1 (in /lib/i686/libpthread-0.9.so) > + by 0x........: main (pth_once.c:65) > + Address 0x........ is on thread 1's stack > + Hm, this looks like it should match against the "LinuxThreads: write/pthread_create" suppression. > + Syscall param write(buf) points to uninitialised byte(s) > + at 0x........: write (in /...libc...) > + by 0x........: main (pth_once.c:65) > + Address 0x........ is on thread 1's stack > + > + Syscall param write(buf) points to uninitialised byte(s) > + at 0x........: write (in /...libc...) > + by 0x........: main (pth_once.c:76) > + Address 0x........ is on thread 1's stack > + > + Syscall param write(buf) points to uninitialised byte(s) > + at 0x........: write (in /...libc...) > + by 0x........: exit (in /...libc...) > + by 0x........: __libc_start_main (...libc...) > + by 0x........: ... > + Address 0x........ is on thread 1's stack These look a bit tricky to suppress. > >> memcheck/tests/scalar (stderr) > > This is asserting on the munlockall test: > > ----------------------------------------------------- > 153: __NR_munlockall 0s 0m > ----------------------------------------------------- > scalar: scalar.c:671: main: Assertion `-1 != res' failed. What's to fail? Or is the kernel missing munlockall altogether? > >> none/tests/yield (stdout) > > > > Can you think of any useful assertion this test could be making? > > Perhaps we should just kill it. > > Well what is it trying to test? Presumably the idea was to test that > the "rep; nop" sequence caused a yield properly. > > Perhaps it is sufficient to test that "rep; nop" makes progress but > less progress that spinning? Yeah, I guess that's all we can say. J |
|
From: Tom H. <th...@cy...> - 2005-01-17 15:02:06
|
In message <1105952911.31917.57.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Mon, 2005-01-17 at 08:44 +0000, Tom Hughes wrote:
>
>> >> none/tests/yield (stdout)
>> >
>> > Can you think of any useful assertion this test could be making?
>> > Perhaps we should just kill it.
>>
>> Well what is it trying to test? Presumably the idea was to test that
>> the "rep; nop" sequence caused a yield properly.
>>
>> Perhaps it is sufficient to test that "rep; nop" makes progress but
>> less progress that spinning?
>
> Yeah, I guess that's all we can say.
Even that isn't good enough... I'm finding the yield test
sometimes hangs and I've just worked out why - sometimes the
rep_nop thread makes no progress at all during the sleep.
Specifically, that thread never reacts to the broadcast before
the sleep is up, so by the time it leaves the cond_wait and
tests the alive flag the flag has been set back to zero and it
goes round the loop again.
I could fix that by using a separate flag to kill the thread
instead of reusing the one that woke it up, but then the test
would fail because the rep_nop count would be zero.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2005-01-17 15:05:40
|
In message <1105952911.31917.57.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Mon, 2005-01-17 at 08:44 +0000, Tom Hughes wrote:
>
>> >> memcheck/tests/scalar (stderr)
>>
>> This is asserting on the munlockall test:
>>
>> -----------------------------------------------------
>> 153: __NR_munlockall 0s 0m
>> -----------------------------------------------------
>> scalar: scalar.c:671: main: Assertion `-1 != res' failed.
>
> What's to fail? Or is the kernel missing munlockall altogether?
The munlockall is failing with EPERM on RH72 through RH9 by the
looks of it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2005-01-17 15:19:48
|
In message <1105952911.31917.57.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Mon, 2005-01-17 at 08:44 +0000, Tom Hughes wrote:
>>
>> + Syscall param write(buf) points to uninitialised byte(s)
>> + at 0x........: write (in /...libc...)
>> + by 0x........: pthread_create@@GLIBC_2.1 (in /lib/i686/libpthread-0.9.so)
>> + by 0x........: main (pth_once.c:65)
>> + Address 0x........ is on thread 1's stack
>> +
>
> Hm, this looks like it should match against the "LinuxThreads:
> write/pthread_create" suppression.
It did, but that was only in the glibc 2.3 file.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|