The feature already exists in our code and produces backtraces upon a
crash into a file. The only difference is that we are now getting the
file contents and showing it in our new debug dialog, so that it works
similarly on all platform (and therefore making the debug info visible
to people, otherwise they would never report, even though the data is
generated).
The difference with gdb/lldb is that it doesn't allow backtraces at
random points (for debugging non-fatal yet bad errors). Also the API has
just 2 functions and in particular an ExcHndlInit() but no way to unload
the feature. So we don't need the debugging page in Preferences because
the switch option would not work. On Windows, the feature will be
decided at build time only.
Last point: the code is untested on Windows so far. I assume it would
work, but there is at least one point I am unsure of: will ExcHndl have
already generated the backtrace file when gimpdebug runs? If not, I will
have to let gimp die first to be able to get the backtrace.
This was a bit harder since even though we handle fatal signals,
allowing us to do any last action before GIMP crashes, it seems more
memory allocation is not allowed at this time. So creating a dialog or
simply getting the return output of gdb into the main process is not
allowed. What I do instead is running a separate program (gimpdebug)
which will take care of creating the new dialog and running a debugger.
I still use GimpCriticalDialog code from this separate binary, while I
continue to use this widget also within GIMP for non-fatal errors. The
reason why we still want to use it within GIMP is that we can bundle
several non-fatal errors and backtrace this way (fatal errors don't
return anyway) and it's easier to do so when created from the main
process.
