On 09/02/16 22:34, Thomas Dineen wrote:
Gentle People:
I am working on a rather large application based on GTK / Cairo
using Mingw GCC for the MS Windows platform.
Debugging has gone well for some time finding and fixing a significant
number of bugs including crash bugs.
However given a fairly complex multi - thread architecture I am
having trouble with GDB finding the specific
code location of code crash bugs. In many cases Mingw GDB dose not
seem usable. (due to the multi - threaded
architecture?). or my lack of GDB skill?
Now the question? Given the Mingw GCC / GDB environment running
on Windows: Is there a simple way to
find the crash point in the code? MS claims an exception! Is there a
way to attach an exception handler to print
out more information about the crash point? Please note that I am
aware of C Exceptions throw and catch which
require implementation in the code.
MS dose provide a Exception Offset when the crash occurs. Is
there any way to use gdb or other tool to find
the crash point in the code. Disassembler? Do the exception addresses
match the offsets found in a tool such as a
disassembler?
Thanks for help or ideas.
Thomas Dineen
First of all, I expect you are compiling with debugging symbols (-ggdb
or at least -g).
And then, when you have a debugger attached to the running program, once
it crashes (no matter on which thread), the debugger will point you
exactly to the point where it happened. At most you may need to browse
the backtrace (bt) to another stack frame (up) to figure out the exact
point in your code (as it may have crashed inside a library you called).
Knowing why it crashed should be relatively straightforward (eg. a null
pointer reference inside the linked list). A different problem may be to
determine why the environment was that way (why there was a null pointer
where none was expected).
Regards
