1. 18 May, 2018 2 commits
  2. 30 Apr, 2018 1 commit
    • Jehan's avatar
      libgimpbase: strengthen other use of g_win32_locale_filename_from_utf8() · 070bcb89
      Jehan authored
      Let's make our various usages of this broken function more robust, or at
      least return with errors when we can. But this is still seriously
      broken. Inside gimp_locale_directory() though, there was nothing I could
      do, so I just added a FIXME for at least keeping an eye on it.
  3. 28 Apr, 2018 1 commit
  4. 26 Apr, 2018 1 commit
  5. 24 Apr, 2018 1 commit
    • Jehan's avatar
      Bug 795510 - SYS_gettid is not available on non-Linux system. · 106fc930
      Jehan authored
      I could not find for sure what to use on FreeBSD instead, so let's just
      not get this information there. It is quite useful information to know
      where thread traces were asked from, but it is more important to make
      sure the program can be compiled everywhere. Also we can just check
      which thread has gimp_stack_trace*() calls. Thus it can be seen as
      redundant information in any case.
      SYS_gettid is apparently defined as a macro, so let's simply check for
      it being defined.
  6. 18 Apr, 2018 1 commit
  7. 14 Apr, 2018 1 commit
  8. 13 Apr, 2018 1 commit
  9. 10 Apr, 2018 1 commit
    • Jehan's avatar
      libgimpbase: improve multi-threaded stack traces. · ae6a7bf9
      Jehan authored
      Since commit bb52431c, we get multi-thread traces in functions
      gimp_stack_trace_*(). Adding now the LLDB equivalent improvement.
      Also adding the process and thread id information, from which the trace
      order was made, atop the listing, as well as the thread list. This would
      allow to easily find and associate the threads.
      The problem is that sometimes the thread where we got a trace from may
      not matter (for instance signals, even such as SIGABRT or SIGSEGV, seem
      to sent a bit randomly to either the thread which provoked them or the
      main thread; there is a bit of contradictory info on this when reading
      on the topic, in my case I experienced this), in such case, getting all
      thread stack is important to find the origin of the signal.
      Other times it will highly matter, in particular when getting a trace
      for a WARNING or CRITICAL. This information will help to discriminate
      between thread traces.
  10. 09 Apr, 2018 2 commits
  11. 08 Apr, 2018 1 commit
    • Ell's avatar
      Makefiles: don't use -xobjective-c when linking files on Mac · 6ebc3f1b
      Ell authored
      Last commit caused -xobjective-c to be passed during linking on
      Mac, causing object files to be treated as source files.  Add a
      -xnone flag to AM_LDFLAGS, canceling the effect of -xobjective-c.
      Additinally, add a -xobjective-c++ flag to AM_CXXFLAGS, so that we
      can use Objective-C in C++ files on Mac, if we ever need to.
  12. 07 Apr, 2018 1 commit
  13. 04 Apr, 2018 1 commit
    • Jehan's avatar
      Bug 794949 - Plugin crash when opening png, jpeg or tiff with... · ba06a0fe
      Jehan authored
      ... non-latin unicode path.
      g_win32_locale_filename_from_utf8() was sometimes returning NULL for
      some paths on Windows. Then the call to gexiv2_metadata_open_path() with
      a NULL value was crashing plug-ins.
      This commit only prevents from crashing by simply failing to load
      metadata when this occurs, which means losing metadata support on
      Windows depending on filenames. A proper solution will have to be
  14. 17 Mar, 2018 1 commit
  15. 15 Mar, 2018 2 commits
  16. 05 Mar, 2018 3 commits
    • Ell's avatar
      libgimpbase: in gimp_stack_trace_print(), shuffle some code around · 86939d84
      Ell authored
      Reap the child *after* we're done reading its output, so that we
      can disable ptracing after reading, but before reaping.  This
      avoids a window during which the child is gone, but ptracing using
      its PID is still allowed.
    • Ell's avatar
      libgimpbase: in gimp_stack_trace_print(), clear ptrace permission on exit · a1a126c3
      Ell authored
      Clear the ptrace permission given to the child after it terminates,
      so that a future process that happens to have the same PID the
      child had can't ptrace us.
    • Ell's avatar
      libgimpbase: in gimp_stack_trace_print(), enable ptrace under Yama · 0f2c966c
      Ell authored
      On Linux, when /proc/sys/kernel/yama/ptrace_scope is 1, a process
      may only ptrace its descendants by default, which prevents the GDB
      process spawned by gimp_stack_trace_print() from attaching to, and
      producing a backtrace for, the calling process.
      Use prctl() with PR_SET_PTRACER, when available, in the parent
      process, to allow the child process to ptrace it.
  17. 22 Feb, 2018 2 commits
    • Michael Natterer's avatar
      libgimpbase: consistent gimp_stack_trace namespace for stack trace functions · 374fee45
      Michael Natterer authored
      Change the rest of the source accordingly.
    • Jehan's avatar
      Bug 793514 - Adding version check for gdb. · 6975188d
      Jehan authored
      It seems that older GDB (under version 7) are not handling very well
      some common debug information format, in particular DWARF > 3. Such
      version of GDB is usually not a problem since it is quite old (more than
      10 years old, it would seem) so you don't see it anymore on any modern
      GNU/Linux distribution. On FreeBSD on the other hand, it is still
      available (probably for license reasons) and even installed by default!
      As a consequence, it makes debugging fail, even though LLDB is also
      installed by default.
      That is even more of a problem because it would seem that GIMP is killed
      (most likely by FreeBSD kernel according to the reporter tests) as a
      side-effect of GDB failing, which is seriously bad, in particular since
      we also use the debug dialog for non-fatal errors (which could therefore
      end up killing GIMP as side effect of a bad GDB!).
      So I add some GDB version check. I implement this without any dynamic
      memory management, as usual, since this needs to happen also during
      crash handling where the state is unstable and prone to memory
      allocation failure.
      I also add gimp_utils_backtrace_available() public API which can be used
      by the Preferences.
  18. 15 Feb, 2018 2 commits
  19. 12 Feb, 2018 2 commits
    • Jehan's avatar
      Bug 793393 - gimputils.c compilation error under Win32. · 1282a95e
      Jehan authored
      The header sys/wait.h is not for Win32.
    • Jehan's avatar
      libgimpbase: allow NULL prog_name in gimp_print_stack_trace(). · 4e293a86
      Jehan authored
      The only debugger command which uses this value currently is gdb. And
      even there, it doesn't look mandatory. The alternative call using "-p"
      option does not require the program name. The manual doesn't say if
      calling with the program name has any advantage (but I don't see why it
      would, the PID is enough to find a process). Just in case, I leave the
      prog_name parameter (because it's easier to make a parameter useless
      than changing a libgimp* API) but simply allows setting it to NULL.
  20. 11 Feb, 2018 2 commits
  21. 09 Feb, 2018 1 commit
  22. 28 Jan, 2018 1 commit
  23. 13 Jan, 2018 1 commit
  24. 11 Jan, 2018 1 commit
  25. 09 Jan, 2018 1 commit
  26. 04 Dec, 2017 1 commit
  27. 01 Dec, 2017 1 commit
  28. 30 Nov, 2017 4 commits
    • Ell's avatar
      libgimpbase: use abbreviations for GimpGradientType · f80f3321
      Ell authored
      Move the abbreviated descriptions to the "abbrev" parameter, and
      use full strings for the descriptions.
    • Ell's avatar
      libgimpbase, app: add abbreviations to gradient enums · d3e527a9
      Ell authored
      The value descriptions of GimpGradientColor,
      GimpGradientSegmentColor, and GimpGradientSegmentType enums appear
      in the on-canvas gradient editor UI, as combo-box items in the tool
      GUI overlay.  Since we want to keep the overlay as small as
      possible, we previously used abbreviations for these descriptions
      (e.g., "FG (t)", instead of "Foreground (transparent)").
      Replace the abbreviated descriptions with unabbreviated ones, and
      move the abbreviations to the "abbrev" parameter.  This way we get
      the abbreviated version in the combo-box, and the full version in
      the combo-box's menu.
    • Ell's avatar
      */Makefile.am: add abbreviations to generated enum files · f7d6805e
      Ell authored
      Update the dprod production of generated enum files to include
      abbreviated value descriptions, as per the previous commits.
      Add a comment for translators above the abbreviated descriptions,
      specifying the full description they abbreviate.
    • Ell's avatar
      libgimpbase: add gimp_{enum,flags}_value_get_abbrev() · 7df42758
      Ell authored
      Add support for specifying an abbreviated description for enum/
      flags values, which can be used in contexts where the full
      description is too long.
      Since the exact layout and size of Gimp{Enum,Flags}Desc is part of
      the ABI, we can't simply add a field to these structs to hold the
      abbreviated description.  Instead, we use the fact that entries
      with a repeated value in the value descriptions array are ignored,
      and that the array is NULL terminated (in particular, that all non-
      NULL entries are followed by at least one additional entry), and
      specify the abbreviation in the "value_desc" field of the entry
      that immediately follows the initial entry for a given value,
      setting the "value" field of both entries to the same value.
      Right now this behavior is undocumented, so there is no proper way
      to specify abbreviated descriptions in the API, and is only meant
      to be used in generated enum files.