You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue discusses a bug related to channel communication in your code.
Describe the bug
While triaging your project, our bug fixing tool generated the following message(s)-
In file: export.go, there is a function ExportFromMongoDB which contains a send or a receive operation on a channel and there is no matching receive or send operation on that channel from another goroutine. The goroutine will be blocking on that channel operation. iCR identified the source of the possible blocking channel operation and suggested to avoid it.
Upon a closer inspection of the code, we found out that the first goroutine inside ExportFromMongoDB sends error over an unbuffered channel done := make(chan error). And inside the select statement in line 176, there's a case for timer timer along with a case for a receive operation on channel done.
If one or more of the communications can proceed, a single one that can proceed is chosen via a uniform pseudo-random selection. Otherwise, if there is a default case, that case is chosen. If there is no default case, the "select" statement blocks until at least one of the communications can proceed.
In that case, if the case of ticker.C is chosen, then the sender end on channel done inside the goroutine will remain halted unless any other goroutine is ready to receive.
It is suggested that such a bug be fixed.
Solution / Fix
Since the send operation on channel done is used in several places, it's best if the author(s) come up with a solution that refactores the affected codes.
Previously Found & Fixed
Such a bug was found in the following project(s) and fixed-
This work is done by the security researchers from OpenRefactory and is supported by the Open Source Security Foundation (OpenSSF): Project Alpha-Omega. Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed – to improve global software supply chain security.
The bug is found by running the Intelligent Code Repair (iCR) tool by OpenRefactory and then manually triaging the results.
The text was updated successfully, but these errors were encountered:
Summary
This issue discusses a bug related to channel communication in your code.
Describe the bug
While triaging your project, our bug fixing tool generated the following message(s)-
Upon a closer inspection of the code, we found out that the first goroutine inside
ExportFromMongoDB
sends error over an unbuffered channeldone := make(chan error)
. And inside theselect
statement in line 176, there's a case for timertimer
along with a case for a receive operation on channeldone
.According to documentation-
In that case, if the case of
ticker.C
is chosen, then the sender end on channeldone
inside the goroutine will remain halted unless any other goroutine is ready to receive.It is suggested that such a bug be fixed.
Solution / Fix
Since the send operation on channel
done
is used in several places, it's best if the author(s) come up with a solution that refactores the affected codes.Previously Found & Fixed
Such a bug was found in the following project(s) and fixed-
Sponsorship and Support
This work is done by the security researchers from OpenRefactory and is supported by the Open Source Security Foundation (OpenSSF): Project Alpha-Omega. Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed – to improve global software supply chain security.
The bug is found by running the Intelligent Code Repair (iCR) tool by OpenRefactory and then manually triaging the results.
The text was updated successfully, but these errors were encountered: