Re: Automated build-and-test summary report (2007/06/18)

[Kris Van Hees <kris dot van dot hees at oracle dot com>]

As reported before on IRC, I am fairly certain that the signals
triggering the failure are actually coming from an earlier test and not
being cleaned up correctly between tests, i.e. a problem with either the
test harness code or some earlier test.  That's also why running just this
particular test tons of time won't bring the problem to light because
nothing is being executed that even posts a SIGUSR1.

	Cheers,
	Kris

On Mon, Jun 18, 2007 at 09:59:12AM -0500, Phil Muldoon wrote:
> Mark Wielaard wrote:
> >Hi,
> >(From the test-results list)
> >
> >On Mon, 2007-06-18 at 05:35 -0700, Kris Van Hees wrote:
> >  
> >>For more detailed results, please check out the reports at:
> >>
> >>    http://build.alchar.org/~aedil/rep/
> >> [...]
> >>  Old   -> New   Test
> >>  -----    ----- ----------------------------------
> >>  PASS  -> FAIL  frysk-core - testStepOver(frysk.rt.TestSteppingEngine)
> >>  PASS  -> FAIL  frysk-core - 
> >>  testCoreFileByteBufferMapOverrun(frysk.proc.corefile.TestCorefileByteBuffer)
> >>  PASS  -> FAIL  frysk-core - 
> >>  testCoreFileByteBufferPoke(frysk.proc.corefile.TestCorefileByteBuffer)
> >>  PASS  -> FAIL  frysk-core - 
> >>  testCoreFileByteBufferPeek(frysk.proc.corefile.TestCorefileByteBuffer)
> >>  PASS  -> FAIL  frysk-core - 
> >>  testCoreFileByteBufferPeekArray(frysk.proc.corefile.TestCorefileByteBuffer)
> >>  PASS  -> FAIL  frysk-core - 
> >>  testCoreFileByteBufferMapUnderrun(frysk.proc.corefile.TestCorefileByteBuffer)
> >>  FAIL  -> PASS  frysk-core - 
> >>  testSliceAddressSpace(frysk.proc.ptrace.TestByteBuffer)
> >>  PASS  -> FAIL  frysk-core - 
> >>  testCoreFileByteBufferSequentialGet(frysk.proc.corefile.TestCorefileByteBuffer)
> >>    
> >
> >The core file tests did once fail for me with a pending SIGUSR1 during
> >teardown.
> The test pass for me on Fedora 7, with:
> 
> ./TestRunner -r 1000 frysk.proc.corefile.TestCorefileByteBuffer
> 
> Running 
> testCorefileByteBufferSlice(frysk.proc.corefile.TestCorefileByteBuffer) 
> ...PASS
> Running 
> testCoreFileByteBufferPeek(frysk.proc.corefile.TestCorefileByteBuffer) 
> ...PASS
> Running 
> testCoreFileByteBufferMapOverrun(frysk.proc.corefile.TestCorefileByteBuffer) 
> ...PASS
> Running 
> testCoreFileByteBufferMapUnderrun(frysk.proc.corefile.TestCorefileByteBuffer) 
> ...PASS
> Running 
> testCoreFileByteBufferSequentialGet(frysk.proc.corefile.TestCorefileByteBuffer) 
> ...PASS
> Running 
> testCoreFileByteBufferPeekArray(frysk.proc.corefile.TestCorefileByteBuffer) 
> ...PASS
> Running 
> testCoreFileByteBufferPoke(frysk.proc.corefile.TestCorefileByteBuffer) 
> ...PASS
> 
> Time: 0.056
> 
> OK (7 tests)
> 
> 
> And it does that for * 1000
> 
> in make check I do see the intermittent  test fails due to
> 
> 1) 
> testCoreFileByteBufferMapUnderrun(frysk.proc.corefile.TestCorefileByteBuffer)junit.framework.AssertionFailedError: 
> pending signal Sig_USR1
> 
> 
> But all these tests are not emitting or listening for signals, I've no 
> idea where that signal is coming from, or how it found it's way into the 
> test.
> 
> However when the corefile tests pass in make check, I see some other 
> test fails such as the one below, come and go:
> 
> There were 6 failures:
> 1) 
> testSliceAddressSpace(frysk.proc.ptrace.TestByteBuffer)junit.framework.AssertionFailedError: 
> unexpected signal Sig_IO
>   at frysk.testbed.AttachedSelf$2.signal(TestRunner)
>   at frysk.sys.Wait.wait(TestRunner)
>   at frysk.sys.Wait.wait(TestRunner)
>   at frysk.testbed.AttachedSelf.<init>(TestRunner)
>   at frysk.proc.ptrace.TestByteBuffer.setUp(TestRunner)
>   at frysk.junit.Runner.runCases(TestRunner)
>   at frysk.junit.Runner.runArchCases(TestRunner)
>   at frysk.junit.Runner.runTestCases(TestRunner)
>   at TestRunner.main(TestRunner)
>