Products

The Jinx Advantage

Jinx is a software quality tool that exposes hard-to-find concurrency bugs in software. It accelerates the rate at which bugs occur in your software, saving you time and resources in the effort to deliver higher quality ThreadSafe applications. With Jinx, your organization can permit its developers to exploit the full power of multi-core processors, provide a safety net for testers to find bugs before they are introduced into production environments, and enable IT administrators to validate full systems comprised of operating systems, drivers, and applications before certifying them as ready for deployment. Jinx provides several benefits, including:

• You can count on Jinx. When Jinx identifies a bug, you can be sure it’s real. There are no false positives with Jinx, saving you a significant amount of time in both finding a bug and determining its veracity. You can count on the results you get from using Jinx.
• Works the way you do. It doesn’t require you to change anything about your software development methodology. It’s integrated with Visual Studio and command line tools on Windows and Linux, and can be easily introduced as part of every continuous integration cycle. It can augment the software testing tools you already use for load and stress testing by forcing bugs to happen faster. And, it can provide a valuable tool for IT administrators to use when building system images for large-scale deployment.
• Easy to use and easy to get started. It takes about five minutes to download the product, install it, and begin using it. There’s no hassle, no fuss, and no complex configuration required.

Jinx holds numerous advantages over traditional software debuggers and development tools in finding concurrency bugs in your software. But Jinx is also designed to work the way you do and augments many of these traditional tools.

Jinx and Traditional Software Debuggers

Traditional software debuggers enable you to examine the state of your programs after a bug has happened. You can view call stacks, threads, and so on. Jinx is different. Jinx actively explores different timings of the various threads in your programs in search of a particular timing combination that will cause a bug to happen. As such, Jinx is complementary to your chosen software debugger. When used together, Jinx can force bugs to happen so that you can use a debugger to examine your program’s state at the time that a bug occurs. And, Jinx’s SmartStop feature helps you pinpoint the exact cause of a bug in your native Windows or Linux code, giving you even more data about a bug.

For example, Jinx for Windows is fully integrated with Microsoft Visual Studio 2008 and Visual Studio 2010. When Jinx finds a bug, SmartStop positions all of the latest Visual Studio 2010 features for writing parallel code (such as the Parallel Stacks window and the Threads window) in the correct position to give you insight into the cause of the bug.

Jinx and Load and Stress Testing Tools

Stress testing attempts to push the boundaries of inputs and system resources for an application in order to find its breaking point. Stress tests may consume a significant amount of system memory in order to ascertain how the application performs in circumstances where available memory is limited. It may flood a machine with unrelated network traffic to determine if the application is still responsive. It may attempt to inflict a denial of service attach on the system to find out whether or not the application can still serve requests to its clients. Ultimately, the goal of stress testing is to exhaustively exercise the inputs and surrounding environment of an application to determine if it can survive when faced with severely limited computational resources.

Similarly, load testing attempts to push the boundaries of the application itself. Load tests may flood an application with an extraordinary number of requests to determine whether or not it can scale to handle those requests. The success or failure of the application to handle these requests is recorded and any failures are logged as bugs.

While the application is being exercised by stress and load tests, Jinx can simulate numerous different timings of thread interleavings in an effort to uncover concurrency errors. Therefore, Jinx actually amplifies the effects of stress testing. If Jinx encounters a particular thread timing that will result in a concurrency error, it makes it happen on the machine and pinpoints the cause.

Stress and load tests are directed at an application executable. Enabling Jinx to run under this application executable is easy. If the name of the application is “application_name”, then a command of “jinx run application_name” will activate Jinx and run the program.

Jinx and Fuzz Testing Tools

Fuzz testing is a technique that involves flooding an application with unexpected, invalid, or random data in an effort to force it to fail. Fuzz testing is typically used with program input or network traffic. For example, a typical web application may contain a user registration form with inputs for name, address, email address, and so on. A fuzz testing tool run on this web application could formulate a wide range of options for inputs including malformed and malicious strings (such as Javascript fragments to help identify logical or security errors in the application.

Similarly, Jinx intelligently and automatically fuzzes the timing of threads in a concurrent application. As the application is running, Jinx intelligently samples slices of execution time and within each slice actively simulates alternatives for thread timing to help uncover a concurrency error. Consequently, together with traditional fuzzing tools, Jinx can introduce a significant amount of “chaos” into parallel programs to force concurrency errors to come to the forefront.

Jinx and Software Lifecycle Tools

Software lifecycle tools help you manage the process of software development by tracking issues, such as work items, bugs, and more. Future versions of Jinx will be able to store data they glean in a bug record for other members of the development team to examine. In so doing, no matter where Jinx discovers bugs, developers will get accurate intelligence about how their applications are executed in production and be able to uncover and fix concurrency errors.

Jinx and Other Concurrency Debuggers

Both writing and debugging parallel applications is a relatively new discipline in our industry. As such, many of the tools that currently claim the ability to find and fix concurrency errors are in their infancy. Many of these tools have several drawbacks, including:

• Numerous false positives. When debuggers flag a number of errors and leave the verification to you, they’re only providing a modicum of assistance. In some ways, it’s good knowing that something could be an error. But with Jinx you get something much more valuable. Jinx only identifies bugs that are positively present in your code. There's no more sifting through endless bug reports to figure out which ones are real. And, with SmartStop, Jinx also identifies the precise location of bugs in your native code.
• Not a dynamic tool. Some debuggers only look at source code. The problem with that for parallel applications is that code itself doesn’t tell you how the operating system will schedule your threads. Static code analysis tools are good at giving you an idea of which variables you should put locking mechanisms around, but they don’t give you insight into bugs, such as race condition bugs, that may occur only when a certain thread timing is present. In contrast, Jinx dynamically analyzes and explores numerous thread timings in an effort to uncover bugs in your code.
• Some tools look at random timing intervals. In an effort to ferret out concurrency bugs, some tools may randomly insert pauses of random lengths into various threads in order to force different thread timings to manifest bugs. The problem with this approach is that it’s akin to shooting a bullet out of the air with another bullet. One common way developers manually look for concurrency errors is to insert thread waits and pauses throughout their program in an effort to uncover a timing issue. Randomly adjusting thread timings merely automates this “press play and pray” approach most commonly employed by developers when concurrency debugging today. In contrast, Jinx intelligently explores various thread timings that will result in bugs manifesting themselves.
• Some tools require changes to your code. One way many tools vendors have approached concurrency is to build special primitives or class libraries that developers have to incorporate into your applications. Unfortunately, this approach requires a significant amount of investment on the part of organizations to train developers in new programming models, languages, or techniques. At Corensic, we believe this is a flawed approach. Jinx does not require any special code or primitives to be inserted into your code. We do provide some primitives that will help you fine tune our engine, but mainly to point out specific areas of your code where you would like Jinx to focus its efforts.

Jinx is an indispensible addition to existing software debuggers, lifecycle tools, and testing tools. It is an easy to use concurrency debugger that positively identifies concurrency bugs while enabling developers to continue to use the development tools and processes they are already familiar with.