Researches On Real-world Concurrency Bugs In Go Language

Concurrent Bugs are difficult to debug and discovered,and are the most widely studied Bugs type in traditional multithreaded programming languages.The Go language is designed to provide a simple,efficient,and secure way to build multi-threaded software.One of Go's main design goals is to improve the traditional multi-threaded programming language,making concurrent programming easier and less error-prone.Understanding Go's new concurrency primitives and mechanisms is crucial to understanding how they affect concurrent Bugs.Concurrent Bugs are difficult to debug and discover,and are the most widely studied Bugs types in traditional multithreaded programming languages.Because there was no previous research on Go s concurrent Bugs.So,so far,it's unclear whether Go's concurrency mechanisms are really easier to apply to concurrent programming than traditional languages,and less prone to errors.This article selects six open source and Go applications in the real-world production environment on the open source community GitHub to conduct empirical research on concurrent Bugs in the Go language,including:Docker and Kubemetes,two data center container systems;Etcd,a distributed key-value storage system;gRPC-Go,an RPC open source framework;CockroachDB and BoltDB,two database systems.In the above application,this article has logged a total of 171 Go concurrent Bugs.The paper reproduces the Bugs,reason analysis,repair strategy analysis and detector testing.This paper has carried out an in-depth analysis of the research results,which has certain guiding significance for future research on Go development,testing and concurrent Bugs detection.The main work of the thesis is as follows:This paper proposes a new method of concurrent Bugs classification,which is classified according to the two orthogonal dimensions of the cause and behavior of the bug.Through this classification method,developers can better understand the two synchronization methods of message passing and shared memory.According to the reason dimension,this article divides Bugs into Bugs caused by misuse of shared memory and Bugs caused by misuse of messaging.According to the second dimension,this article divides the collected Bugs into goroutines(called blocking Bugs)that cannot be executed(any number)and Bugs that do not involve any blocking(non-blocking Bugs).This classification also helps researchers better compare the different concurrency mechanisms and the correlation between the causes of concurrent bugs and the repair strategy.This paper suggests that other Bugs studies can also use similar classification methods.'The research in this paper shows that messaging and shared memory are as easy to generate concurrent Bugs,and sometimes messaging is more likely to generate concurrent Bugs than shared memory.This conclusion is contrary to the usual view.For example,about 58%of blocked Bugs are caused by messaging.In addition to violating the usage rules of Channel in Go(for example,waiting on a channel that does not send data or close),many concurrent Bugs are caused by the mixing of messages in Go and other new semantics and new libraries.It is easy to be ignored and hard to find.This paper proposes six static detection algorithms and two possible dynamic detection algorithms that can be used to detect concurrent Bugs caused by Go's new features.This paper collects the Bugs in the actual application software to verify the above detection algorithm,and the results show that these algorithms are effective.Based on these algorithms,some new bugs are also found in this paper.The proposed algorithms lay the foundation for the detection of Go's concurrent Bugs.The research in this paper shows that although Go has made great improvements in simplifying concurrent programming,if developers do not understand these features deeply enough,then it is easy to generate concurrent Bugs when writing concurrent programs using Go.The results of this paper will not only allow Go developers to deepen their understanding of Go concurrency,but also allow Go language designers to re-examine Go's new features.It can also be used to answer both messaging and shared memory access in concurrent mode.The controversy between the methods also provides a theoretical basis and guidance for the development of high-quality Go concurrent programs and related concurrent Bugs detection tools.