Jinx Debugger

Article summary

Jinx was a concurrency debugger that deterministically controlled the interleaving of workloads across processor cores, focusing on shared memory interactions. Using this deterministic approach, Jinx aimed to increase the frequency of occurrence of elusive shared memory bugs, sometimes called Heisenbugs. Jinx is no longer available. Corensic, the company that was developing Jinx, was bought by F5 Networks and the Jinx project was cancelled. Jinx worked by dynamically building a set of potential interleavings (i.e. alternate eventualities, or execution scenarios, that will occur under some future condition) that are most likely to result in concurrency faults, and quickly tested those execution paths to surface concurrency problems such as deadlocks, race conditions and atomicity violations that are found in multiprocessing applications. Unlike model checkers, Jinx did not require the specification of a model. Unlike dynamic and static code analysis methods, Jinx was notable in that it produced no false positives (spurious bug reports). This was because Jinx tested the scenarios that are likely to be bugs, as opposed to just inferring those scenarios by analyzing source code or observing the execution of a program. Jinx was implemented as a hypervisor, giving it the ability to observe the effects of all elements of the software environment on thread interleaving.…

Key claims

No claims recorded.

Discussion questions

1. Summarise the article in your own words. Which single claim would you verify first, and why?
2. Which claim in this article is most likely to be revised as the sources update? How would you check its current status?
3. If two sources disagreed about one of these facts, what would you need in order to trust one over the other?

Bibliography

No sources recorded.