Imagine this scenario: You are relatively new to a very large codebase for a GUI application. A bug report comes in. Since it is a GUI, the report is not expressed in terms relating to functions or exceptions raised from the code, instead it has screenshots of the GUI, descriptions, maybe a video.

What strategies do you use to identify the relevant code?

Note that this is nothing to do with the quality of the bug report; we can assume that it is very good.


First you reproduce the bug. Then you run your system in the debugger and halt at a place that you know the control flow will pass through. The stack frames at that point tell you what route through the system this use case takes.

Obviously the important point is to pick a place in the code base that is actually as close to the point of trouble as possible. If the issue is with the GUI itself (e.g. wrong label on a button), you have to halt somewhere within the GUI code. If it is with the result of an operation, the point of trouble comes much later, when data are actually processed and results delivered. If an error is deep within the processing logic, you might even be able to reproduce it simply by giving different inputs to an existing unit test and forego running the live system altogether (except for verifying that you can reproduce the issue in the first place, of course).

  • Yes, the problem is in your very first point. 'Halt at a place you know the control flow will pass through'. In a application with say ~10k source files, finding this place is the problem – jramm Oct 24 '17 at 7:20
  • 4
    @jramm If you have no idea at all where control flow might pass through, then the real problem is unfamiliarity with the code base. The canonical question about this is "How to dive into large code bases": softwareengineering.stackexchange.com/questions/6395 – Kilian Foth Oct 24 '17 at 7:27
  • @jramm you have screenshots, so you can start from those GUI classes. – mmathis Oct 24 '17 at 16:15

Bisecting search. You have some input which leads to an unexpected output. There is probably a large stack of code involved in getting from input to output. You have to get a rough idea of the layers and operations involved. Then you pick a point somewhere in the middle of this, and determine if the expected output is already wrong at this point. This will cut the area of the possible bug in half. Do this a few times, and you have isolated the bug.

Start at the boundaries between subsystems. For example, if you have a REST API it is easy to execute a request and inspect the result. If SQL is involved it is easy to execute SQL and inspect the result. Anywhere you have a well-specified interface, it is easier to check input vs. output.

  • Yes this is a good plan, I imagine this means going through the steps to reproduce the bug numerous times, each time setting a break point (or multiple), roughly in the area that you think is going to be hit. Then look at the call stack to see either where to go next (if the bug already happened), or to help figure out the flow to set a break point in the future. – jramm Oct 24 '17 at 7:29
  • @jramm: Exactly. And of course this is easier said than done, since you need a good understanding of the code to decide on these point, and determine what is correct input/output. But bisecting allows you to quickly eliminate large parts of the code base from the investigation. – JacquesB Oct 24 '17 at 9:33

From your comment,

In a application with say ~10k source files, finding this place is the problem

In an application of this size, there should be some logging / tracing options built into the application. This is almost a requirement for applications of this size, including GUIs.

Among the logging / tracing options, one of the option should be to print out the location, class name, or the function name of the code being executed, even if the code being executed thinks that everything is going normally (without an exception). Depending on how logging is actually used throughout the application, this may require increasing the logging level to DEBUG or VERBOSE.

The code not detecting an abnormal condition when one has actually happened is in itself a software defect. Additionally, sometimes the current software behavior is exactly as the programmer has intended - except that it doesn't agree with the user's requirements or specification. In both cases, you will want to see the execution trace, not just the exception report.

Enable it, and see where execution hits while you perform the bug reproduction steps. Use the logs as the starting point for further investigation.

If the application does not implement adequate logging / tracing to allow you to investigate the bug, bring this issue to the project lead. If the application does not have any logging / tracing at all, I guess the problem is bigger than the code base itself, and it will require more people to solve.


A way to go would to to retrieve as much information as possible from the reports (video report very useful) and try to reproduce the bug. You can still use break points from the first method that your button invokes and from there you can dive deeper. My recommendation would be to identify the point of entry(example a main class) to your app. Based on my experience, the best way is to reproduce the bug in the running app.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.