1. 28 Jan, 2018 21 commits
    • Piotr Drąg's avatar
      Update POTFILES.in and POTFILES.skip · 0ac29c0b
      Piotr Drąg authored
      0ac29c0b
    • Jehan's avatar
      app: add SIGABRT to be handled by gimp_fatal_error(). · 07e8ce36
      Jehan authored
      SIGABRT is definitely a fatal error, at least in GIMP context. It is
      used by g_assert() and more generally by abort().
      
      Actually I am a bit unsure about the difference of gimp_terminate() and
      gimp_fatal_error(). The former mostly depends on whether we used
      --debug-handlers or not, which reads "Enable non-fatal debugging signal
      handlers". But the way we handle them, the list of signals handled by
      gimp_terminate() seem to always end up fatal as well, anyway. So either
      we should *really* make them non-fatal (I could imagine that SIGTERM or
      SIGINT indeed could be better handled for instance), or we should just
      get rid of this terminate/fatal_error differentiation which seems
      totally artificial and non-existing in the current code.
      07e8ce36
    • 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.
      fe3cf080
    • Jehan's avatar
      b8fa968b
    • Jehan's avatar
      app, tools: install the debug tools in libexec when appropriate. · b318694b
      Jehan authored
      AFAIK this means on all platforms but Win32 and macOS which would rather
      need relative path and therefore cannot make use of build-time
      LIBEXECDIR. Anyway on these platforms, leaving the binary in BINDIR is
      not likely to "pollute" too much as it would on Linux or BSD where
      people often use terminal.
      b318694b
    • Jehan's avatar
      app: make the backtrace GUI actually work on Win32. · 4e5a5dbb
      Jehan authored
      It was previously untested, hence as expected needed fixes. First I add
      our own exception handler using Win32 API SetUnhandledExceptionFilter().
      Second, I reorder things so that ExcHndlInit() is run after this setter,
      since they will be executed as a FILO and we need backtraces to be
      generated before our separate GUI runs. Last I run the backtrace GUI as
      async. No need to keep the main GIMP waiting since the traces have
      already been generated into a separate file.
      
      Also replace gtk_show_uri() by the implementation taken straight from
      our web-browser plug-in, since apparently gtk_show_uri() doesn't work in
      Windows (and probably not macOS either since I see we have a separate
      implementation for this platform as well). I would like to be able to
      use the PDB but can't because this code needs to be usable both within
      the main process and into a separate tool process. Ideally, this should
      just be a utils function which could be included without a problem.
      4e5a5dbb
    • 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
      9ca8899a
    • Jehan's avatar
      pdb: oups! I previously edited a generated file. · a700b15e
      Jehan authored
      This is the PDB I had to edit instead of app/pdb/message-cmds.c which is
      generated.
      a700b15e
    • 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
      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.
      ae3cd00f
    • Jehan's avatar
      015f2fc8
    • Jehan's avatar
      app: add a debugging page in preferences. · 270730d5
      Jehan authored
      Move the backtracing settings there. This page may also be used later
      for auto-saving on crashes, as discussed in bug 792787, or similar
      features.
      270730d5
    • Jehan's avatar
      app: add lldb as backtrace-creator alternative to gdb. · 4ca31b05
      Jehan authored
      It seems that on some platforms (macOS in particular), this may be more
      common to have.
      4ca31b05
    • Jehan's avatar
      app: test G_OS_WIN32 rather than G_OS_UNIX for new backtrace feature. · eab961c9
      Jehan authored
      This is just a bit more consistent with existing code. Also build the
      gimpdebug tool only when GIMP_CONSOLE_COMPILATION is not set and run
      when --no-interface CLI option is not set since it is a GUI tool.
      eab961c9
    • Jehan's avatar
      app: add a "generate-backtrace" preference in GimpCoreConfig. · f8411a3d
      Jehan authored
      This will determine whether to output backtrace in a GUI and is disabled
      by default on stable, and activated in dev builds. It is a bit redundant
      with --stack-trace-mode option CLI and will take priority when enabled
      since most people would run GIMP with a graphical interface anyway.
      f8411a3d
    • 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: reimplement gimp_get_stack_trace(). · bb88a2d5
      Jehan authored
      Don't use g_on_error_stack_trace() from glib anymore. It is
      over-complicated, using gdb in interactive mode and running command
      writing in the pipe input. Sometimes it even gets stuck and never
      return. This is useless since gdb even has a batch mode, to just run
      commands and exit directly. I just use this.
      bb88a2d5
    • 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
    • Michael Natterer's avatar
      app: fix GimpToolCompass for one perfectly vertical line · 5da3bdb4
      Michael Natterer authored
      the angle arc and the small helper line were displayed on opposite
      sides of the first point. Now they are on the same side, just like for
      all other angles.
      5da3bdb4
    • Michael Natterer's avatar
      Bug 792981 - Measure tool is measuring one pixel to the right of initial point · c71535b7
      Michael Natterer authored
      This reverts 2069496a for
      gimpmeasuretool.c, we can't use gimp_display_shell_get_line_status()
      here because the angle to show is *not* the angle as shown in the
      paint tools (between x1,y1 and x2,y2), it is determined by a possible
      third point.
      
      Also, the info window and the statusbar were using different
      coordintates to detemine the line length. This would have been easily
      fixable, but the wrong angle wasn't.
      c71535b7
    • Dimitris Spingos's avatar
      Update Greek translation · da4f03b8
      Dimitris Spingos authored
      da4f03b8
  2. 27 Jan, 2018 13 commits
  3. 26 Jan, 2018 1 commit
  4. 25 Jan, 2018 1 commit
  5. 23 Jan, 2018 2 commits
  6. 22 Jan, 2018 2 commits