Cannot Reproduce a Bug? – DZone

The phrase “it really works on my machine” could be a supply of amusement, however it additionally represents a prevailing perspective on the earth of growth – an perspective that always forces customers to show bugs earlier than we’re prepared to research them. 

Woman standing in front of a maze of pathsHowever in actuality, we have to take duty and chase the difficulty, no matter the place it takes us.


A Two-Pronged Method to Bug Fixing

Fixing bugs requires a two-pronged method. Initially, we wish to replicate the atmosphere the place the difficulty is happening; it could possibly be one thing particular to the consumer’s machine. Alternatively, we might have to resort to distant debugging or use logs from the consumer’s machine, asking them to carry out sure actions on our behalf.

Just a few years again, I used to be attempting to duplicate a bug reported by a consumer. Regardless of matching the JVM model, OS, community connectivity, and so forth, the bug merely would not present up. Finally, the consumer despatched a video displaying the bug, and I observed they clicked in another way throughout the UI. This highlighted the truth that typically, the bug copy course of is not only within the machine, but additionally within the consumer conduct.

The Position of Consumer Habits and Communication in Bug Fixing

In these conditions, it’s essential to isolate consumer conduct as a lot as attainable. Utilizing video to confirm the conduct can show useful. Understanding the refined variations within the replicated atmosphere is a key a part of this, and open, clear communication with the one that can reproduce the issue is a should.

Nonetheless, there may be hurdles. Typically, the particular person reporting the difficulty is from the assist division, whereas we is perhaps within the R&D division. Typically, the client is perhaps upset, inflicting communication to interrupt down. That is why I imagine it is important to combine the R&D division with the assist division to make sure a smoother decision of points.

Tools and Techniques for Bug Solving

Several tools such as stracedtrace, and others can provide deep insights into a running application. This information can help us pinpoint differences and misbehaviors within the application. The advent of container technology like Docker has greatly simplified the creation of uniform environments, eliminating many subtle differences.

I was debugging a system that only failed at the customer’s location. It turns out that their network connection was so fast, the round trip to the management server was completed before our local setup code finished its execution. I tracked it down by logging in remotely to their on-site machine and reproducing the issue there. Some problems can only manifest in a specific geographic location.

There are factors like networking differences, data source differences, and scale that can significantly impact the environment. How do you reproduce an issue that only appears when you have 1,000 requests per second in a large cluster? Observability tools can be extremely helpful in managing these situations. In that situation the debugging process changes, it’s no longer about reproducing but rather about understanding the observable information we have for the environment as I discussed here.

Ideally, we shouldn’t reach these situations since tests should have the right coverage. However, in practice, this is never the case. Many companies have “long-run” tests designed to run all night and stress the system to the max. They help discover concurrency issues before they even occur in the wild. Failures were often due to lack of storage (filled up everything with logs) but often when we got a failure it was hard to reproduce. Using a loop to re-run the code that failed many times was often a perfect solution. Another valuable tool was the “Force Throw” feature I discussed previously. This allowed us to fail gracefully and pass stumbling blocks in the long run.


Logging is an important feature of most applications; it’s the exact tool we need to debug these sorts of edge cases. I talked and wrote about logging before and its value.

Yes, logging requires forethought much like observability. We can’t debug an existing bug without logging “already in place.” Like many things, it’s never too late to start logging properly and pick up best practices.


If a bug is elusive the odds of a concurrency-related issue are very high. If the issue is inconsistent then this is the place to start, verifying the threads involved and making sure the right threads are doing what you expect.

Use single thread breakpoints to pause only one specific thread and check if there’s a race condition in a specific method. Use tracepoints where possible instead of breakpoints while debugging – blocking hides or changes concurrency-related bugs, which are often the reason for the inconsistency.

Review all threads and try to give each one an “edge” by making the other threads sleep. A concurrency issue might only occur if some conditions are met. We can stumble onto a unique condition using such a technique.

Try to automate the process to get a reproduction. When running into issues like this, we often create a loop that runs a test case hundreds or even thousands of times. We do that by logging and trying to find the problem within the logs.

Notice that if the problem is indeed an issue in concurrent code, the extra logging might impact the result significantly. In one case I stored lists of strings in memory instead of writing them to the log. Then I dumped the complete list after execution finished. Using memory logging for debugging isn’t ideal, but it lets us avoid the overhead of the logger or even direct console output (FYI console output is often slower than loggers due to lack of filtering and no piping).

When to “Give Up”

While it’s never truly recommended to “give up,” there may come a time when you must accept that reproducing the issue consistently on your machine is not feasible. In such situations, we should move on to the next step in the debugging process. This involves making assumptions about the potential causes and creating test cases to reproduce them.

In cases where we cannot resolve the bug, it’s important to add logging and assertions into the code. This way, if the bug resurfaces, we’d have more information to work with.

The Reality of Debugging: A Case Study

At Codename One, we had been utilizing App Engine when our day by day billing all of the sudden skyrocketed from a number of {dollars} to lots of. The potential value was so excessive it threatened to bankrupt us inside a month. Regardless of our greatest efforts, together with educated guesses and fixing the whole lot we might, we had been by no means capable of pinpoint the precise bug. As an alternative, we needed to remedy the issue by means of brute power.

In the long run, bug-solving is about persistence and fixed studying. It is about not solely accepting the bug as part of the event course of but additionally understanding how we will enhance and develop from every debugging expertise.


The adage “it really works on my machine” typically falls quick on the earth of software program growth. We should take possession of bugs, attempting to duplicate the consumer’s atmosphere and behaviors as carefully as attainable. Clear communication is essential, and integration between R&D and assist departments may be invaluable.

Trendy instruments can present deep insights into operating purposes, serving to us to pinpoint issues. Whereas container applied sciences, like Docker, simplify the creation of uniform environments, variations in networking, knowledge sources, and scale can nonetheless impression debugging.

Typically, regardless of our greatest efforts, bugs cannot be persistently reproduced on our machines. In such instances, we have to make educated assumptions about potential causes, create check instances that reproduce these assumptions, and add logging and assertions into the code for future debugging help.

In the long run, debugging is a studying expertise that requires persistence and adaptableness and is essential for the expansion and enchancment of any developer.