What Jinx Does For Your Multi-Threaded Code
Jinx makes your code "unlucky"
by proactively causing it to crash
so you can investigate why it did so.
Corensic builds software quality tools that enable businesses to safely exploit the full power of multi-core processors to deliver ThreadSafe systems. Using Corensic’s award-winning products, businesses can find bugs faster during development, communicate more efficiently about bugs found during testing, and validate full system stacks prior to deployment.
Jinx is a software quality tool that exposes hard-to-find concurrency bugs at design-time, saving developers and QA professionals time and improving application reliability. Jinx examines your software and intelligently selects slices of execution time within which to probe deeper for bugs. Within each time slice, Jinx evaluates numerous possibilities for the timing of how various threads within an application interact with one another and execute, and chooses a particular schedule of thread execution that is most likely to cause a bug. As a result, Jinx makes your code “unlucky” by proactively causing it to crash so that you can investigate why it did so.
Jinx helps you understand how threads are communicating when a program error occurs. When a program crash is detected Jinx will not only stop the crashing thread at the problematic source code line (as all debugging tools will do), but it stops all other threads in your application at the earliest point in time when the bug would still have occurred, so that you can obtain an accurate picture of the state of your application when a bug was caused (as no other debugging tool can do).
Jinx gives you a photo of
the "crime scene" (the application state)
at the moment the concurrency bug occurred.
We call this feature SmartStop.
In the forensics of evaluating bugs in multi-core applications, the first step is knowing that bugs, or “crimes” are occurring. Jinx also gives you a photo of the “crime scene” (the application state) at the moment the concurrency bug occurred. We call this feature SmartStop. One of the hardest challenges with debugging parallel code is that you often only see one side of the problem. You know which thread detected incorrect program state or wandered off on a bad pointer. But you don’t see which thread actually corrupted program state or wrote that bad pointer value to begin with. SmartStop lets you see this thread at that exact point.
Jinx ordinarily lies dormant below the operating system. However, when applications register with the debugger to be tested, Jinx takes control of your operating system. Execution of the machine then proceeds in two phases: a simulation phase and a replay phase. In the simulation phase, Jinx examines your software and intelligently selects slices of execution time within which to probe deeper for bugs. Within each time slice, Jinx evaluates numerous possibilities of for the timing of how various threads within an application interact with one another and execute, and chooses a particular schedule of thread execution that is most likely to cause a bug.
In the replay phase, Jinx then takes the possibility that is most likely to cause a bug and makes it happen on the actual operating system environment. If a bug occurs, Jinx notifies you, either through the IDE or the command line interface. As a result, Jinx makes your code “unlucky” by proactively causing it to crash so that you can investigate why it did so.
Jinx enables you to get more insight into potential errors
in your software and the efficacy of
your concurrency testing processes.
We call this feature Reports.
In addition to accelerating bugs and stopping them in the debugger intelligently via SmartStop, Jinx Reports can provide information about buggy and likely-buggy code in your application. Jinx Reports allows use of SmartStop in test automation environments where use of a debugger may not be practical. It provides greater insight into how concurrent code gets executed, and likely errors in it. Jinx Reports also fills a major gap in determining the efficacy of concurrency testing by enabling the construction of a concurrent coverage metric that describes how much coverage particular interleavings of threads have received.
Jinx Reports creates a shareable artifact that organizes potential errors in your software, each of which is referred to as an event. These events include assertion failures (which are, by definition, errors), NULL pointer dereferences (which are usually errors), machine level events such as General Protection Faults, and data races. Jinx Reports also offers a fast and effective race detector that is based on Jinx's simulation/exploration process (explained above) and leverages SmartStop to provide more detailed information about potential errors. The data races contained in a Jinx Report are often valid errors, though not always. The Jinx Reports race detector can also analyze code running in kernel mode, making it the world's first and only kernel-mode race detector. Jinx Reports can be stored and included in bug reports after, for example, a test automation harness is run on your software. Consult the Jinx documentation Wiki for more technical information about the contents of a Jinx Report.
Most development and test organizations are familiar with the concept of code coverage. Code coverage gives you an understanding of which lines of code have been exercised by your unit tests. It is a useful metric that can help you ensure that your software is being adequately tested. Unfortunately, code coverage alone is insufficient in the world of parallel development. Concurrent programs don't always exhibit the same behavior from one execution to the next. For that reason, Jinx Reports also provides the world's first and only concurrency coverage analysis tool. Jinx Reports can give you insight into how much of your code is being "Jinxed," and, therefore, being tested for concurrency errors. This can help you make sure that you are exercising your software sufficiently so that Jinx can detect potential concurrency errors.
"Our software teams have found that by using Jinx in our software development and testing, we have been able to find concurrency software defects in minutes instead of the 12 hours that would have been required with conventional testing."
Citrix Systems