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).
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.
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.
