1. 11 Jul, 2018 1 commit
  2. 12 Feb, 2018 2 commits
    • Jehan's avatar
      app: make backtrace processed in the thread where error happens. · b0cd4412
      Jehan authored
      Slight back step from commit 34fe992f. I don't keep track anymore of
      the number of errors inside GimpCriticalDialog. The problem is that GTK+
      calls must happen in the main thread, and errors in another thread will
      be delayed into the main thread through gdk_threads_add_idle_full().
      This makes any backtrace generated as a consequence of a threaded error
      useless (in particular any error happening in GEGL since we always
      process these as multi-threaded, whether they are or not).
      Instead I now keep track of the number of errors in gui-message.c, which
      still allows to reset the counters when the unique debug dialog is
      closed. Therefore I can now generate backtraces conditionally to the
      error counters inside the problematic thread (and right when the error
      happened), without any GTK+ call.
      This finally makes GEGL backtraces useful in the debug dialog! :-)
      b0cd4412
    • Jehan's avatar
      app: keep track of number of errors and traces in GimpCriticalDialog. · 34fe992f
      Jehan authored
      We don't want an infinite number of traces because it takes some time to
      get. Until now I was keeping track of traces in app/errors.c, but that
      was very sucky because then I was limiting traces per session. Instead
      save them as a variable of a GimpCriticalDialog instance. Therefore only
      generate the traces for WARNING/CRITICAL at the last second, when
      calling the dialog.
      When too many traces are displayed, just fallback to just add error
      messages only. But then even errors without traces can be time-consuming
      (if you have dozens of thousands of errors in a few seconds, as I had
      the other day, updating the dialog for all of them would just freeze the
      whole application for a long time).
      So also keep track of errors as well and as last fallback, just send the
      remaining errors to the stderr.
      34fe992f
  3. 31 Jan, 2018 1 commit
  4. 30 Jan, 2018 1 commit
  5. 28 Jan, 2018 4 commits
    • Jehan's avatar
      app: remove the "save your work and restart" advice on fatal errors. · ee6e981c
      Jehan authored
      This is obviously not possible anymore to do this manually so this step
      is bogus in a crash case. We keep this step for other (non-fatal)
      errors. We may add an automatic "attempt" to save in a backup file
      later, which may not work depending on how bad the crash is (which is
      why it will be done in a backup file, we don't want to corrupt saved
      files).
      ee6e981c
    • Jehan's avatar
      app, tools: various fixes for Win32 build. · a3a4df95
      Jehan authored
      * Type pid_t is not cross-platform. Just use int instead, and convert it
        to respective type on each platform.
      * Get rid of several useless include which should have been removed a
        few commits ago, when I reimplemented the backtrace function.
      * Better handle the various macros in gimp_eek() (between G_OS_WIN32,
        HAVE_EXCHNDL and GIMP_CONSOLE_COMPILATION, but also no_interface and
        generate_backtrace options, that was a bit messy).
      * Make gimpdebug now always built, whatever the platform.
      a3a4df95
    • 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
      process.
      beede171
    • Jehan's avatar
      app: new error dialog to backtrace and encourage people to report bugs. · 9fdf3555
      Jehan authored
      GIMP will now try to get a backtrace (on Unix machines only for now,
      using g_on_error_stack_trace(); for Windows, we will likely have to look
      into DrMinGW).
      This is now applied to CRITICAL errors only, which usually means major
      bugs but are currently mostly hidden unless you run GIMP in terminal. We
      limit to 3 backtraces, because many CRITICAL typically get into domino
      effect and cause more CRITICALs (for instance when a g_return*_if_fail()
      returns too early).
      9fdf3555