EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: [Bug 1951848] Re: Failing EPICS 7 libCom tests on VxWorks 6.7 and 6.9
From: Dirk Zimoch via Core-talk <core-talk at aps.anl.gov>
To: core-talk at aps.anl.gov
Date: Tue, 23 Nov 2021 16:55:34 -0000
epicsStdioTest: This one succeeds when running in a writable directory. However:
Ran 165 tests but only planned for 163!

Looking for more test count mismatch...
epicsMessageQueueTest: Planned 74 tests but only ran 0
epicsMutexTest: Ran 51 tests but only planned for 20!
epicsSpinTest: Ran 6 tests but only planned for 2!
epicsStringTest: Ran 431 tests but only planned for 427!
epicsThreadOnceTest: Ran 12 tests but only planned for 11!
Amazing.

-- 
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1951848

Title:
  Failing EPICS 7 libCom tests on VxWorks 6.7 and 6.9

Status in EPICS Base:
  New

Bug description:
  epicsThreadTest

  # System has 1 CPUs
  ok  1 - ncpus > 0
  # main() thread 0x581810
  not ok  2 - Join delayed parent (0 seconds) # TODO Thread join doesn't work
  ok  3 - Join tests #1 completed
  not ok  4 - Join delayed parent (0 seconds) # TODO Thread join doesn't work
  ok  5 - Join tests #2 completed
  not ok 12 - infoB.didSomething
  not ok 13 - infoA.didSomething
  not ok 14 - threadA epicsThreadIsOkToBlock() = 88
  not ok 15 - threadB epicsThreadIsOkToBlock() = 7001716

      Results
      =======
         Tests: 15
        Passed:  11 = 73.33%
        Failed:   4 = 26.67%

  Behaves differently when called from :

  # System has 1 CPUs
  ok  1 - ncpus > 0
  # main() thread 0x539d10
  not ok  2 - Join delayed parent (0 seconds) # TODO Thread join doesn't work
  ok  3 - Join tests #1 completed
  not ok  4 - Join delayed parent (0 seconds) # TODO Thread join doesn't work
  ok  5 - Join tests #2 completed
  ok  6 - pget == pset
  ok  7 - thread.getPriority() == epicsThreadGetPriority(self)
  ok  8 - pget == pset
  ok  9 - thread.getPriority() == epicsThreadGetPriority(self)
  ok 10 - pget == pset
  ok 11 - thread.getPriority() == epicsThreadGetPriority(self)
  not ok 12 - infoB.didSomething
  not ok 13 - infoA.didSomething
  ok 14 - threadA epicsThreadIsOkToBlock() = 0

  Planned 15 tests but only ran 14

      Results
      =======
         Tests: 14
        Passed:  12 = 85.71%
        Failed:   2 = 14.29%
  ok 15 - threadB epicsThreadIsOkToBlock() = 1

  Test results are counted before the test completes!
  Why do test 14 and 15 only succeed when called from epicsRunLibComTests but fail when running epicsThreadTest directly? Because the test passes a pointer to a local variable which already went out of scope before being used (because epicsThreadMustJoin did not work).

  --------------

  epicsEventTest (TODO)

  not ok 16 - epicsEventWaitWithTimeout(0.125000)  delay error -0.008332 sec # TODO Known issue with delay calculation
  not ok 17 - epicsEventWaitWithTimeout(0.062500)  delay error -0.012501 sec # TODO Known issue with delay calculation
  not ok 18 - epicsEventWaitWithTimeout(0.031250)  delay error -0.014585 sec # TODO Known issue with delay calculation

      Results
      =======
         Tests: 37
        Passed:  37 = 100.00%
   Todo Passes:  19 = 51.35%

  --------------

  epicsSockResolveTest

  not ok 26 - aToIPAddr("127.0.0.test", 4000) -> 0
  #   IP=0x7f000000, port=4000
  not ok 27 - aToIPAddr("127.0.0.test:42", 4000) -> 0
  #   IP=0x7f000000, port=42
  not ok 30 - aToIPAddr("1.2.3.4.5", 4000) -> 0
  #   IP=0x1020304, port=4000
  not ok 31 - aToIPAddr("1.2.3.4.5:6", 4000) -> 0
  #   IP=0x1020304, port=6

      Results
      =======
         Tests: 37
        Passed:  33 = 89.19%
        Failed:   4 = 10.81%

  This fails because the VxWorks 6.7 implementation of hostGetByName
  happily reads rubbish as the 4th numeric component as 0 and ignores
  any further components. Fixed in vxWorks 6.9.

  --------------

  epicsStdioTest (not really a bug: r/o NFS mount)

  not ok 152 - (stream = fopen(report, "w")) != NULL
  # 'report' could not be opened for writing: S_nfsLib_NFSERR_ROFS
  ok 153 # SKIP Can't create stream file
  ok 154 # SKIP Can't create stream file
  ok 155 # SKIP Can't create stream file
  ok 156 # SKIP Can't create stream file
  ok 157 # SKIP Can't create stream file
  ok 158 # SKIP Can't create stream file
  ok 159 # SKIP Can't create stream file
  ok 160 # SKIP Can't create stream file
  ok 161 # SKIP Can't create stream file
  ok 162 # SKIP Can't create stream file
  ok 163 # SKIP Can't create stream file

      Results
      =======
         Tests: 163
        Passed: 162 = 99.39%
        Failed:   1 =  0.61%
       Skipped:  11 =  6.75%

  --------------

  macDefExpandTest

  # Got "", expected "BAR".

  not ok 27 - ${=BAR}
  # Got "xy", expected "xBARy".

  not ok 28 - x${=BAR}y

      Results
      =======
         Tests: 97
        Passed:  95 = 97.94%
        Failed:   2 =  2.06%

  This is a result of previous epicsEnvUnset calls because vxWorks has
  no way to unset enviroment variables and thus the implementation
  deletes the name. This effectively creates a variable with empty name
  and thus ${} and ${=BAR} return an empty string.

  Running this test a second time fails more often because some environment variables are now defined, e.g.
  not ok 77 - Macro F is 6, expected undefined

      Results
      =======
         Tests: 97
        Passed:  79 = 81.44%
        Failed:  18 = 18.56%

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1951848/+subscriptions


References:
[Bug 1951848] [NEW] Failing EPICS 7 libCom tests on VxWorks 6.7 Dirk Zimoch via Core-talk

Navigate by Date:
Prev: Re: Strange UDP message on VxWorks 6.9 Johnson, Andrew N. via Core-talk
Next: [Bug 1951848] Re: Failing EPICS 7 libCom tests on VxWorks 6.7 and 6.9 Dirk Zimoch via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
Navigate by Thread:
Prev: [Bug 1951848] Re: Failing EPICS 7 libCom tests on VxWorks 6.7 and 6.9 Andrew Johnson via Core-talk
Next: [Bug 1951848] Re: Failing EPICS 7 libCom tests on VxWorks 6.7 and 6.9 Dirk Zimoch via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
ANJ, 24 Nov 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·