Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Build failed in Jenkins: epics-base-3.16-linux32-test #13
From: Andrew Johnson <anj@aps.anl.gov>
To: <core-talk@aps.anl.gov>
Date: Mon, 15 Feb 2016 18:07:46 -0600
On 02/15/2016 05:33 PM, Michael Davidsaver wrote:
> On 02/12/2016 12:33 PM, Andrew Johnson wrote:
>> On 02/12/2016 11:06 AM, APS Jenkins wrote:
>>> src/std/rec/test/O.linux-x86/arrayOpTest.tap ............. ok
>>> src/std/rec/test/O.linux-x86/asTest.tap .................. ok
>>> Bailout called.  Further testing stopped:  testMonitorWait() exceeds timeout
>>> FAILED--Further testing stopped: testMonitorWait() exceeds timeout
>> My fix was just to re-run the tests; given that this failure has
>> happened before on a different architecture, I think the 10 second
>> timeout delay in testMonitorWait() is just too short for a busy build
>> slave. Since the effect of failure is to kill all further testing I have
>> bumped it all the way up to 60 seconds.
> 
> It's happened again.  From the .tap log the timeout is a symptom of a
> previous failure.  I'm guessing this was the case previously.

This time it failed on the linux-x86_64 Jenkins master CPU; previously
it was on the linux-x86 (i.e. 32-bit) build slave, so the two are not
quite the same.

>> 1..10
>> ############################################################################
>> ## EPICS R3.16.0-DEV $$Date$$
>> ## EPICS Base built Feb 15 2016
>> ############################################################################
>> ok  1 - dbGetField("rec:ai", 8) -> 0.000000e+00 == 0.000000e+00
>> ok  2 - dbGetField("rec:ai.INP", 0) -> "0" == "0"
>> not ok  3 - dbPutField(rec:link1.PROC, 5, ...) == -1
>> Bail out! testMonitorWait() exceeded 60 second timeout
> 
> I haven't yet been able to replicate this locally.

IIRC previous failures didn't show any failed tests before testAbort()
was called, so this may be a different problem and not just a case of a
too-busy CPU. Could there be something racy in the above test?

- Andrew

-- 
There are only two hard problems in distributed systems:
  2. Exactly-once delivery
  1. Guaranteed order of messages
  2. Exactly-once delivery
 -- Mathias Verraes

Replies:
Re: Build failed in Jenkins: epics-base-3.16-linux32-test #13 Michael Davidsaver
References:
Build failed in Jenkins: epics-base-3.16-linux32-test #13 APS Jenkins
Re: Build failed in Jenkins: epics-base-3.16-linux32-test #13 Andrew Johnson
Re: Build failed in Jenkins: epics-base-3.16-linux32-test #13 Michael Davidsaver

Navigate by Date:
Prev: Re: Build failed in Jenkins: epics-base-3.16-linux32-test #13 Michael Davidsaver
Next: Re: Build failed in Jenkins: epics-base-3.16-linux32-test #13 Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019 
Navigate by Thread:
Prev: Re: Build failed in Jenkins: epics-base-3.16-linux32-test #13 Michael Davidsaver
Next: Re: Build failed in Jenkins: epics-base-3.16-linux32-test #13 Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019 
ANJ, 15 Feb 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·