Baris Kasikci

Learn More
Even though most data races are harmless, the harmful ones are at the heart of some of the worst concurrency bugs. Alas, spotting just the harmful data races in programs is like finding a needle in a haystack: 76%-90% of the true data races reported by state-of-the-art race detectors turn out to be harmless [45]. We present Portend, a tool that not only(More)
Some of the worst concurrency problems in multi-threaded systems today are due to data races---these bugs can have messy consequences, and they are hard to diagnose and fix. To avoid the introduction of such bugs, system developers need discipline and good data race detectors; today, even if they have the former, they lack the latter. We present RaceMob, a(More)
Bugs often lurk in code that is infrequently executed (i.e., cold code), so testing and debugging requires tracing such code. Alas, the location of cold code is generally not known a priori and, by definition, cold code is elusive during execution. Thus, programs either incur unnecessary runtime overhead to " catch " cold code, or they must employ sampling,(More)
Developers spend a lot of time searching for the root causes of software failures. For this, they traditionally try to reproduce those failures, but unfortunately many failures are so hard to reproduce in a test environment that developers spend days or weeks as ad-hoc detectives. The shortcomings of many solutions proposed for this problem prevent their(More)
Data races are one of the main causes of concurrency problems in multithreaded programs. Whether all data races are bad, or some are harmful and others are harmless, is still the subject of vigorous scientific debate [Narayanasamy et al. 2007; Boehm 2012]. What is clear, however, is that today's code has many data races [Kasikci et al. 2012; Jin et al.(More)
One of the most energy-draining and frustrating parts of software development is playing detective with elusive bugs. In this paper we argue that automated post-mortem debugging of failures is feasible for real, in-production systems with no runtime recording. We propose reverse execution synthesis (RES), a technique that takes a coredump obtained after a(More)
Modern concurrent software is riddled with data races and these races constitute the source of many problems. Data races are hard to detect accurately before software is shipped and, once they cause failures in production, developers find it challenging to reproduce and debug them. Ideally, all data races should be known before software ships. Static data(More)
One of the main reasons debugging is hard and time consuming is that existing debugging tools do not provide an explanation for the root causes of failures. Additionally , existing techniques either rely on expensive runtime recording or assume existence of a given program input that reliably reproduces the failure, which makes them hard to apply in(More)
Deadlocks are hard to find via traditional testing, and they manifest rarely during program execution. We introduce Lockout, a technique and a tool that increases the probability of deadlock manifestation in multithreaded programs, while preserving the program semantics and requiring no perturbation to the runtime and the testing infrastructure. Lockout(More)
  • J R Larus, G Candea, V Adve, Prof J Kinder, Prof W Zwaenepoel, N Thèse +12 others
  • 2015
die naïve Ausführung des Interpreters. Chef ist unter Abstract Manual software testing is laborious and prone to human error. Yet, among practitioners, it is the most popular method for quality assurance. Automating the test case generation promises better effectiveness, especially for exposing corner-case bugs. Symbolic execution stands out as an automated(More)