1. 10 Mar, 2018 2 commits
    • Ell's avatar
      app-tools: fix gimp-debug-tool usage message · bf6d9b7f
      Ell authored
    • Ell's avatar
      tools, app-tools: move gimp-debug-tool from tools/ to app-tools/ · 5893d2dc
      Ell authored
      Move gimp-debug-tools.c from tools/ to a new app-tools/ subdir,
      which should contain external tools needed by app/, and which is
      built *after* app/ (unlinke tools/).  This allows gimp-debug-tool
      to depend on libapp and libappwidgets, instead of on actual source
      files from app/.  Building sources from app/ in another subdir
      screws with the distclean rules, and breaks distcheck.
  2. 08 Feb, 2018 1 commit
    • Jehan's avatar
      app, tools: use the new gimp_print_stack_trace() to output the... · 8d2ae895
      Jehan authored
      ... stacktrace into a file on non-Win32 systems.
      This has a few advantages:
      - First, we don't need to duplicate stacktrace code inside the
        independent gimp-debug-tool (I even noticed that the version in the
        tool was gdb-only and not updated for lldb fallback; proof that code
        duplication is evil!). Instead, even on a crash, we can create the
        stacktrace from the main binary and simply pass it as a file.
      - Secondly, that allows to fallback to the backtrace() API even for
        crashes (this was not possible if the backtrace was done from a
        completely different process). That's nice because this makes that we
        will always get backtraces in Linux (even though backtrace() API is
        not as nice as gdb/lldb, it's better than nothing).
      - Finally this makes the code smaller (i.e. easier to maintain), more
        consistent and similar on all platforms.
  3. 04 Feb, 2018 1 commit
  4. 28 Jan, 2018 3 commits
    • Jehan's avatar
      app, tools: title capitalize the debug dialog titles. · fe3cf080
      Jehan authored
      Also rename it to "GIMP Debug" and "GIMP Crash Debug" for continuable
      errors and fatal errors respectively.
    • Jehan's avatar
      app, tools: add support for ExcHndl/DrMinGW for Win32 debugging. · ae3cd00f
      Jehan authored
      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
      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.
    • Jehan's avatar
      app, tools: add backtrace GUI for crashes as well. · beede171
      Jehan authored
      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