01org / ciao / 195 / 2
56%
master: 66%

LAST BUILD BRANCH: topic/config-subnet-bits
DEFAULT BRANCH: master
Ran
Files 67
Run time 3s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 64.01% (+0.007%) from 64.003%
COVERALLS_TOKEN=mwTn1pOFqEOUT13vylZNHq53NanoMznO7

push

travis-ci

tpepper 
ssntp: silence go race report in ssntp client

Ssntp client.go threads call sync.WaitGroup functions which read
and write the client.frameWg data member.  The waitgroups themselves
intrinsically can be written and read from multiple contexts safely.
But that doesn't mean the counts are coherent.

It is possible that the Close() function starts to Wait() on the
waitgroup _just_ before a new frame comes in and calls Add(1).  Then
the wait is waiting on less than the intended count and can close the
client.frameRoutinesChannel which would result in a write to a
closed channel and a panic.  We're not hitting that panic, but that
potential is probably what is being noted by go-race (does go-race not
have a VERBOSE option?).

There already is a client.status variable that is toggled to ssntpClosed
state.  But it is only checked in the error path of the frame processor
not in the non-error path.  There's a slight gap there for a race, which
is then fixed by grabbing the client.status lock, checking for ssntpClosed
status and returning rather than doing the Add(1) and processing the new
frame (ie: discard frames that come just in the "closing" window).

This was observed in ciao-controller's TestDeleteInstance()
unit test when run with go-race.  That test no longer reports
error in go-race after the patch.

Signed-off-by: Tim Pepper <timothy.c.pepper@linux.intel.com>

9355 of 14615 relevant lines covered (64.01%)

0.69 hits per line

Source Files on job 195.2 (COVERALLS_TOKEN=mwTn1pOFqEOUT13vylZNHq53NanoMznO7)