Formal verification of concurrent software

Chockler, Hana; Farchi, Eitan; Glazberg, Ziv; Godlin, Benny; Nir-Buchbinder, Yarden; Rabinovitz, Ishai

doi:10.1145/1147403.1147406

Cited by 5 publications

(4 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Numerous works have embraced formal verification of concurrent (distributed) systems [10,30,29,20]. The work in [19] focus for example on hardware but with asynchronous mode.…”

Section: The Basic Contextmentioning

confidence: 99%

Can Component/Service-Based Systems Be Proved Correct?

Attiogbé

2009

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Component-oriented and service-oriented approaches have gained a strong enthusiasm in industries and academia with a particular interest for service-oriented approaches. A component is a software entity with given functionalities, made available by a provider, and used to build other application within which it is integrated. The service concept and its use in web-based application development have a huge impact on reuse practices. Accordingly a considerable part of software architectures is influenced; these architectures are moving towards service-oriented architectures. Therefore applications (re)use services that are available elsewhere and many applications interact, without knowing each other, using services available via service servers and their published interfaces and functionalities. Industries propose, through various consortium, languages, technologies and standards. More academic works are also undertaken concerning semantics and formalisation of components and service-based systems. We consider here both streams of works in order to raise research concerns that will help in building quality software. Are there new challenging problems with respect to service-based software construction? Besides, what are the links and the advances compared to distributed systems?Comment: 16 page

show abstract

“…Numerous works have embraced formal verification of concurrent (distributed) systems [10,30,29,20]. The work in [19] focus for example on hardware but with asynchronous mode.…”

Section: The Basic Contextmentioning

confidence: 99%

Can Component/Service-Based Systems Be Proved Correct?

Attiogbé

2009

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…For example, a case study involving testing and model checking was conducted by Chockler et al, who compared ConTest and the ExpliSAT model checker using two real programs at IBM [6]. The results of the case study focused on the usage and the comprehensiveness of the results of each tool.…”

Section: Related Workmentioning

confidence: 99%

Comparative Assessment of Testing and Model Checking Using Program Mutation

Bradbury

Cordy

Dingel

2007

Testing: Academic and Industrial Conference Practice and Research Techniques - MUTATION (TAICPART-MUTATION 2007)

View full text Add to dashboard Cite

“…Thus, if the server reads the value of stop and next the shutdown function is executed, then the call to notify() precedes the call to wait(), and the server enters a deadlock. After extracting the business code that is not related to concurrency [3], the program contains 72 possible instrumentation points.…”

Section: Automatically Debugging a Server Loopmentioning

confidence: 99%

Instrumenting where it hurts

Tzoref

Yom-Tov

2007

Proceedings of the 2007 International Symposium on Software Testing and Analysis

View full text Add to dashboard Cite

As concurrent and distributive applications are becoming more common and debugging such applications is very difficult, practical tools for automatic debugging of concurrent applications are in demand. In previous work, we applied automatic debugging to noise-based testing of concurrent programs. The idea of noise-based testing is to increase the probability of observing the bugs by adding, using instrumentation, timing "noise" to the execution of the program. The technique of finding a small subset of points that causes the bug to manifest can be used as an automatic debugging technique. Previously, we showed that Delta Debugging can be used to pinpoint the bug location on some small programs.In the work reported in this paper, we create and evaluate two algorithms for automatically pinpointing program locations that are in the vicinity of the bugs on a number of industrial programs. We discovered that the Delta Debugging algorithms do not scale due to the non-monotonic nature of the concurrent debugging problem. Instead we decided to try a machine learning feature selection algorithm. The idea is to consider each instrumentation point as a feature, execute the program many times with different instrumentations, and correlate the features (instrumentation points) with the executions in which the bug was revealed. This idea works very well when the bug is very hard to reveal using instrumentation, correlating to the case when a very specific timing window is needed to reveal the bug. However, in the more common case, when the bugs are easy to find using instrumentation (i.e., instrumentation on many subsets finds the bugs), the correlation between the bug location and in- * This work is partially supported by the European Community under the Information Society Technologies (IST) programme of the 6th FP for RTD -project SHADOWS contract IST-035157. The authors are solely responsible for the content of this paper. It does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of data appearing therein.

show abstract

Formal verification of concurrent software

Cited by 5 publications

References 13 publications

Can Component/Service-Based Systems Be Proved Correct?

Can Component/Service-Based Systems Be Proved Correct?

Comparative Assessment of Testing and Model Checking Using Program Mutation

Instrumenting where it hurts

Contact Info

Product

Resources

About