From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1169 invoked by alias); 18 Jun 2007 15:15:45 -0000 Received: (qmail 1158 invoked by uid 22791); 18 Jun 2007 15:15:44 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME X-Spam-Check-By: sourceware.org Received: from rgminet01.oracle.com (HELO rgminet01.oracle.com) (148.87.113.118) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Jun 2007 15:15:39 +0000 Received: from rgmsgw02.us.oracle.com (rgmsgw02.us.oracle.com [138.1.186.52]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l5IFFR3F005867; Mon, 18 Jun 2007 09:15:27 -0600 Received: from ca-server1.us.oracle.com (ca-server1.us.oracle.com [139.185.48.5]) by rgmsgw02.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l5IFFQ2v007491 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2007 09:15:27 -0600 Received: from kvanhees by ca-server1.us.oracle.com with local (Exim 4.63) (envelope-from ) id 1I0Iww-0000Pq-Ad; Mon, 18 Jun 2007 08:15:26 -0700 Date: Mon, 18 Jun 2007 15:39:00 -0000 From: Kris Van Hees To: Phil Muldoon Cc: Mark Wielaard , frysk@sourceware.org Subject: Re: Automated build-and-test summary report (2007/06/18) Message-ID: <20070618151525.GN17138@ca-server1.us.oracle.com> References: <20070618123542.GJ17138@ca-server1.us.oracle.com> <1182170677.4534.35.camel@dijkstra.wildebeest.org> <46769DC0.70102@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46769DC0.70102@redhat.com> User-Agent: Mutt/1.5.11 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00313.txt.bz2 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.(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) >