mystran wrote: ↑
Wed Nov 24, 2021 10:19 pm
Crash report will tell you where the crash happens, but it won’t tell you what caused it. It is often the case that the actual crash site is not the location of a bug, but rather it’s just crashing because of invalid data and/or heap corruption and the actual problem might be pretty much anywhere.
Well, I don’t know what kind of crash reports you deal with but the crash reports that we get are full of useful information to begin chasing down a problem. Information such as the module (library) in which the crash occurred, along with the complete stack trace, provides significant clues as to what happened. We can generally tell immediately whether the crash is in the plugin or in the main application. If it’s the former we can be pretty sure (it’s never 100% but extremely likely) that the bug is in the plugin because we know from experience that our calls into the plugin via the SDK are themselves unlikely to be the issue.
The report, along with symbolification of the debug symbol tables, lets us see the actual call hierarchy in the source code. That information, along with experience with the product lets one begin to form a hypothesis as to what MIGHT be the most likely cause from which one can create tests to try and reproduce the issue. Often, the actual cause it is often immediately obvious from looking at the source code at each line of the stack trace.
These days, with language and/or library features such as better dynamic memory management (e.g. the C++ unique_ptr mechanism) and the ability to do run time checking of array bounds (for example), heap corruption, though never impossible, is much less likely.
Obviously there are no guarantees but it’s an extremely valuable first step.
Read more here: Source link