This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Jinx Debugger" – news · newspapers · books · scholar · JSTOR (February 2018) (Learn how and when to remove this message)

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.^[1]

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. Jinx operated independently of any programming language or threading libraries or tools.

Jinx was developed by a (now defunct) company named Corensic in Seattle, Washington based on research performed at the University of Washington^[2] and initially presented at the ASPLOS conference of 2009.