Concurrency bugs in open source software: a case study

Asadollah, Sara Abbaspour; Sundmark, Daniel; Eldh, Sigrid; Hansson, Hans

doi:10.1186/s13174-017-0055-2

Cited by 17 publications

(13 citation statements)

References 24 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…These include the multitude of programming languages and the programming paradigms supported by these languages, various libraries and tools that provide multithreading, as well as hardware properties, and all this effectively prevents the development of one comprehensive method. It should also be added that not all errors related to multithreading can be easily classified and then reproduced for repair [5]. Therefore, in practice, it is possible to locate a number of errors such as race condition, atomicity violation, order violation and deadlock, but also those that do not fit into the category of race-related errors or the deadlock-type errors [6].…”

Section: A Characteristics Of Selected Methodsmentioning

confidence: 99%

“…Out of all the errors discussed in this paper, the order violation error is the least studied one, which is why it is also the most frequently misclassified error (often mistaken for atomicity violation) [40]. Research conducted in 2017 shows that both programmers and testers are usually unable to provide the correct sequence of thread execution [5], i.e. knowledge of the scenario predicted by the architect or programmer implementing the indicated functionality is sometimes negligible among other team members.…”

Section: ) Order Violationmentioning

confidence: 97%

“…significant errors and 1 are the most significant errors. The data on the working time needed to fix various types of bugs were also analyzed and it shows that repairing errors in multithreaded applications took an average of 82 days, while repairing errors in single-threaded applications takes an average of 66 days [5]. Combined with the fact that very often the first code modification does not resolve the [5] error, it can be concluded that the average time spent by developers fixing bugs in multithreaded applications is too short.…”

Section: ) Order Violationmentioning

confidence: 99%

See 2 more Smart Citations

Detection of Concurrency Errors in Multithreaded Applications Based on Static Source Code Analysis

Giebas

Wojszczyk

2021

IEEE Access

View full text Add to dashboard Cite

Computer systems that allow multithreaded execution of applications have become extremely common, even small portable devices operate in multithreaded mode. This is undoubtedly very convenient for users, but for programmers it is associated with many unwanted errors, which can occur after writing application code. These errors include race condition, deadlock, atomicity violation and order violation. The subject of this work is related to the detection of these errors in the process of static software analysis. The paper presents the author's model, which was then used to detect the above-mentioned occurrences, additionally each error has been discussed in detail. A tool supporting the detection of errors in multithreaded applications was also developed and the results of this tool were presented.

show abstract

Section: A Characteristics Of Selected Methodsmentioning

confidence: 99%

Section: ) Order Violationmentioning

confidence: 97%

Section: ) Order Violationmentioning

confidence: 99%

See 1 more Smart Citation

Detection of Concurrency Errors in Multithreaded Applications Based on Static Source Code Analysis

Giebas

Wojszczyk

2021

IEEE Access

View full text Add to dashboard Cite

show abstract

“…System software reduces execution time by spawning multiple threads and splitting tasks. As a drawback, it suffers from various bugs not existing in the sequential setting: data races, deadlock, starvation, etc [18].…”

Section: Introductionmentioning

confidence: 99%

Concrat: An Automatic C-to-Rust Lock API Translator for Concurrent Programs

Hong¹,

Ryu²

2023

Preprint

View full text Add to dashboard Cite

Concurrent programs suffer from data races. To prevent data races, programmers use locks. However, programs can eliminate data races only when they acquire and release correct locks at correct timing. The lock API of C, in which people have developed a large portion of legacy system programs, does not validate the correct use of locks. On the other hand, Rust, a recently developed system programming language, provides a lock API that guarantees the correct use of locks via type checking. This makes rewriting legacy system programs in Rust a promising way to retrofit safety into them. Unfortunately, manual C-to-Rust translation is extremely laborious due to the discrepancies between their lock APIs. Even the state-of-the-art automatic C-to-Rust translator retains the C lock API, expecting developers to replace them with the Rust lock API. In this work, we propose an automatic tool to replace the C lock API with the Rust lock API. It facilitates C-to-Rust translation of concurrent programs with less human effort than the current practice. Our tool consists of a Rust code transformer that takes a lock summary as an input and a static analyzer that efficiently generates precise lock summaries. We show that the transformer is scalable and widely applicable while preserving the semantics; it transforms 66 KLOC in 2.6 seconds and successfully handles 74% of real-world programs. We also show that the analyzer is scalable and precise; it analyzes 66 KLOC in 4.3 seconds. of the Linux kernel will support Rust code [23]. Android and Fuchsia implementations also use RustReimplementing concurrent programs in Rust is, however, labor-intensive if done manually. The discrepancies between the lock APIs of C and Rust hinder programmers from mechanical rewriting. They have to understand the use of the C lock API in original programs and restructure the programs to express the intended logic with the Rust lock API. It poses the necessity for a tool for automatic C-to-Rust translation.The state-of-the-art C-to-Rust translator, C2Rust [58], is still far from alleviating the burden on programmers. The translation of C2Rust is completely syntactic and generates Rust code using the C lock API. Programmers are expected to replace the C lock API in C2Rust-generated code with the Rust lock API for thread safety. While being better than nothing,

show abstract

“…A technical aspect of FOSS development is addressed by the paper "Concurrency bugs in open source software: a case study" [61] by Sara Abbaspour Asadollah and her colleagues. In this paper, the authors are interested in better understanding the differences between concurrency-related bugs and other bugs by analyzing bug reports from five Apache projects.…”

Section: Papers Included In This Thematic Seriesmentioning

confidence: 99%