This repository was archived by the owner on Jul 1, 2024. It is now read-only.
Fix beacon WatchDeviceChanges memory leak #183
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
WatchDeviceChangesfunction creates a goroutine that watches for any change notifications coming from the underlying Device. The result ofb.Parseis sent to the channelchusing a blocking send. Because of this, the caller toWatchDeviceChangesmust continuously empty this channel otherise the goroutine will simply hang on this line, meaning it will never exit and result in a goroutine leak. So the caller code looks something like this:This brings us onto the second issue: the channel
chis only closed when the contextctxis done. However, the goroutine can also exit due tob.propchangedsending anil, which occurs whenUnwatchDeviceChangesis called. In this case,chis never closed, which means the caller toWatchDeviceChangesthat is emptyingchwill never quit, again resulting in a goroutine and channel leak. Closing the channel using adeferat the beginning of the goroutine resolves this issue.In addition, when the context reports that it is done, instead of
returning from the function, it just breaks, which continues the loop and can potentially cause a panic if it tries to write to the channelch.The call to
ctx.Doneis meaningless on line 66. I'm guessing the intention was to cancel the context, which is not possible from this function.