Failing EPICS 7 libCom tests on VxWorks 6.7 and 6.9
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| EPICS Base |
New
|
Undecided
|
Unassigned | ||
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 epicsThreadIsOk
not ok 15 - threadB epicsThreadIsOk
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.
ok 8 - pget == pset
ok 9 - thread.
ok 10 - pget == pset
ok 11 - thread.
not ok 12 - infoB.didSomething
not ok 13 - infoA.didSomething
ok 14 - threadA epicsThreadIsOk
Planned 15 tests but only ran 14
Results
=======
Tests: 14
Passed: 12 = 85.71%
Failed: 2 = 14.29%
ok 15 - threadB epicsThreadIsOk
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 - epicsEventWaitW
not ok 17 - epicsEventWaitW
not ok 18 - epicsEventWaitW
Results
=======
Tests: 37
Passed: 37 = 100.00%
Todo Passes: 19 = 51.35%
--------------
epicsSockResolv
not ok 26 - aToIPAddr(
# IP=0x7f000000, port=4000
not ok 27 - aToIPAddr(
# IP=0x7f000000, port=42
not ok 30 - aToIPAddr(
# IP=0x1020304, port=4000
not ok 31 - aToIPAddr(
# 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_
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%
| summary: |
- Failing libCom tests on VxWorks + Failing EPICS 7 libCom tests on VxWorks 6 |
| summary: |
- Failing EPICS 7 libCom tests on VxWorks 6 + Failing EPICS 7 libCom tests on VxWorks 6.7 |
| description: | updated |
| description: | updated |
| description: | updated |
| summary: |
- Failing EPICS 7 libCom tests on VxWorks 6.7 + Failing EPICS 7 libCom tests on VxWorks 6.7 and 6.9 |
| description: | updated |
| description: | updated |
| description: | updated |
| description: | updated |
| Andrew Johnson (anj) wrote | #1 |
| Dirk Zimoch (dirk.zimoch) wrote | #2 |
| Dirk Zimoch (dirk.zimoch) wrote | #3 |
| Dirk Zimoch (dirk.zimoch) wrote | #4 |
| Dirk Zimoch (dirk.zimoch) wrote | #5 |
I don't have access to any VxWorks 6.x installations earlier than 6.8 and I don't generally run the EPICS tests on that because we don't use it any more here at APS. PSI is the only EPICS site that I know of which is actively working with VxWorks < 6.9 now.
Re epicsStdioTest: You may be able to get this test to pass if you use ftp to boot and your ftp server has access to a writable directory. I have an 'incoming' directory which is world-writable and I can cd to "server:
Re macDefExpandTest: Thanks for that explanation, that makes sense (I was seeing these failures too). I can modify macCore.c's lookup() routine to check for a NULL or empty name before it calls getenv() and return NULL in that case — that's a 1-line change:
--- a/modules/
+++ b/modules/
@@ -588,7 +588,7 @@ static MAC_ENTRY *lookup( MAC_HANDLE *handle, const char *name, int special )
}
if ( (special == FALSE) && (entry == NULL) &&
- char *value = getenv(name);
+ char *value = name && *name ? getenv(name) : NULL;
if (value) {
entry = create( handle, name, FALSE );
if ( entry ) {
It looks like we shouldn't be passing either into getenv() anyway, so this is a legitimate change for the other targets too. I just committed that change along with my fix to add redirect support for vprintf() to epicsStdio.h which fixed those failures.