Experimental Physics and
Industrial Control System

My latest Appveyor job for epics-base showed a couple of failures, in the pvAccess testChannelAccess tests (which are unrelated to the CA provider or my commits that triggered this build), and an unexplained core-dump analysis of the testCaProvider tests after a silent access violation. I'm just writing this to record what I've found out about it, I'm not expecting anyone else to delve further given that it's a very rare thing.

Build epics-base base-7.0-48 failed

Commit 2fbaa7f926 by Andrew Johnson on 2/8/2022 9:29 PM:
Improve POD documentation of the TSE and TSEL fields

C:/projects/epics-base/modules/pvAccess/testApp/O.windows-x64-debug

15337testAtomicBoolean.tap ..... ok

15338testHexDump.tap ........... ok

15339testInetAddressUtils.tap .. ok

15340configurationTest.tap ..... ok

15341testFairQueue.tap ......... ok

15342testWildcard.tap .......... ok

15343testChannelAccess.tap .....

15344not ok 25 - void __cdecl ChannelAccessIFTest::test_channel(void): a destroy event was caught for the testing channel that was destroyed twice

15345Failed 5/152 subtests

15346 (less 12 skipped subtests: 135 okay)

15347testCodec.tap ............. ok

15348testRPC.tap ............... ok

15349testServerContext.tap ..... ok

15350testmonitorfifo.tap ....... ok

15351testsharedstate.tap ....... ok

15352

15353Test Summary Report

15354-------------------

15355testChannelAccess.tap (Wstat: 0 Tests: 148 Failed: 1)

15356 Failed test: 25

15357 Parse errors: Tests out of sequence. Found (23) but expected (21)

15358 Tests out of sequence. Found (24) but expected (22)

15359 Tests out of sequence. Found (25) but expected (23)

15360 Tests out of sequence. Found (26) but expected (24)

15361 Tests out of sequence. Found (27) but expected (25)

15362Displayed the first 5 of 129 TAP syntax errors.

15363Re-run prove with the -p option to see them all.

15364Files=12, Tests=6191, 0 wallclock secs ( 0.33 usr + 0.00 sys = 0.33 CPU)

15365Result: FAIL

15366-------------------

15367

15368

15369

The failing part of the testChannelAccess.tap file looks like this:

ok 20 - void __cdecl ChannelAccessIFTest::test_channel(void): channel connection state connected
# void __cdecl ChannelAccessIFTest::test_channel(void): destroying the channel
#SyncChannelRequesterImpl.channelStateChange:2
#ok 21 - SyncChannelRequesterImplvoid __cdecl ChannelAccessIFTest::test_channel(void): channel created count should be the same on the destroyed channel.
channelStateChange:3not ok 22 -
void __cdecl ChannelAccessIFTest::test_channel(void): channel state change count should increase on the destroyed channel
ok 23 - void __cdecl ChannelAccessIFTest::test_channel(void): channel should not be connected
ok 24 - void __cdecl ChannelAccessIFTest::test_channel(void): channel connection state DESTROYED
# void __cdecl ChannelAccessIFTest::test_channel(void): destroying the channel yet again
not ok 25 - void __cdecl ChannelAccessIFTest::test_channel(void): a destroy event was caught for the testing channel that was destroyed twice
# BEGIN TEST void __cdecl ChannelAccessIFTest::test_channelGetWithInvalidChannelAndRequester(void):
#SyncChannelRequesterImpl.channelCreated(Status [type=OK])
#SyncChannelRequesterImpl.channelStateChange:1
ok 26 # SKIP  creating a channel get with a null channel

Unfortunately the test code is emitting other text to stdout which is messing up the tap output, the two magenta-colored test results above aren't being seen or counted properly by the test harness, resulting in it reporting tests of of sequence. There are still 2 failing tests above though, #22 and #25, but only on this VS-2019 dynamic-debug build.

Then at the end of the build log there is a core-dump and exception analysis of the testCaProvider.exe test program, which didn't show up as failing any tests or dying when it was run but does seem to have silently dumped a core file. This shows a destruction problem during atexit cleanups. Whether it's related to an issue in the caProvider itself or the combination of running a local CA client and an IOC in the same process isn't easy to tell though. I probably won't look at this any further unless it starts happening elsewhere.

- Andrew

-- 
Complexity comes for free, Simplicity you have to work for.

Replies:

Re: Appveyor build failures from pvAccessCPP Michael Davidsaver via Core-talk

References:

Build failed: epics-base base-7.0-48 AppVeyor via Core-talk

Navigate by Date:

Prev: Build failed: epics-base base-7.0-48 AppVeyor via Core-talk

Next: Re: Appveyor build failures from pvAccessCPP Michael Davidsaver via Core-talk

Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <2022>  2023  2024 

Navigate by Thread:

Prev: Build failed: epics-base base-7.0-48 AppVeyor via Core-talk

Next: Re: Appveyor build failures from pvAccessCPP Michael Davidsaver via Core-talk

Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <2022>  2023  2024