akovalenko/lnd.xprv
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

peer: in chanMsgStream release lock for condition var after msg q pop

Browse Source 
In this commit we fix an existing bug within the msgConsumer grouting
of the chanMsgStream that could result in a partial deadlock, as the
readHandler would no longer be able to add messages to the message
queue. The primary cause of this issue would be if we got an update for
a channel that “we don’t know of”. The main loop would continue,
leaving the mutex unlocked. We would then try to re-lock at the top of
the loop, leading to a deadlock.

We avoid this situation by properly unlocking the condition variable as
soon as we’re done modifying the condition itself.
This commit is contained in:
Olaoluwa Osuntokun 2017-10-19 19:45:01 -07:00
parent 00ee3afab8
commit 4cf4fd377f
No known key found for this signature in database
GPG Key ID: 964EA263DD637C21
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
peer.go
View File

@ -566,6 +566,8 @@ func (c *chanMsgStream) msgConsumer() {
c.msgs[0] = nil // Set to nil to prevent GC leak. c.msgs[0] = nil // Set to nil to prevent GC leak.
c.msgs = c.msgs[1:] c.msgs = c.msgs[1:]
c.msgCond.L.Unlock()
// We'll send a message to the funding manager and wait iff an // We'll send a message to the funding manager and wait iff an
// active funding process for this channel hasn't yet // active funding process for this channel hasn't yet
// completed. We do this in order to account for the following // completed. We do this in order to account for the following
@ -587,7 +589,6 @@ func (c *chanMsgStream) msgConsumer() {
} }
c.chanLink.HandleChannelUpdate(msg) c.chanLink.HandleChannelUpdate(msg)
c.msgCond.L.Unlock()
} }
} }