1. 03 Sep, 2018 1 commit
    • Ell's avatar
      app, tools: add "running" thread attribute to GimpBacktrace/performance-log · 78adb7c9
      Ell authored
      The "running" attribute (readable through
      gimp_backtrace_is_thread_running(), and recorded in the performance
      log) specifies if the thread was in a running or suspended state at
      the time the backtrace was taken.  It is accurate on Linux, but
      only approximated on Windows.
      
      Adapt the performance-log-expand.py tool to maintain this attribute
      (and any future thread attributes we might add).
      78adb7c9
  2. 02 Sep, 2018 1 commit
    • Ell's avatar
      tools: add performance-log-related tools · d7c74a61
      Ell authored
      performance-log-expand.py decodes a delta-encoded performance log
      by expanding the deltas, producing a log where each sample (and
      other relevant elements) contain complete information.  Note that
      the structure of expanded logs is identical to that of delta-
      encoded logs, the expanded log simply has no deltas.
      
      performance-log-resolve.py resolves symbol information in
      backtraces.  The logs produced by GIMP only specify the program
      counter at each stack frame, providing an address-map to map
      program-counter addresses to actual symbols separately.  This tool
      looks up each program-counter address in the address map,
      incorporating the relevant symbol information directly into the
      backtrace.
      
      Both tools read their input from STDIN, and write their output to
      STDOUT, and can be chained in a pipeline (with
      gimp-performance-log-expand.py appearing first).
      
      Note that these tools require Python 3.
      d7c74a61
  3. 20 Aug, 2018 1 commit
  4. 12 Aug, 2018 1 commit
    • Jehan's avatar
      tools: fix linking error. · 14614969
      Jehan authored
      Though no error was raised during a native build, a cross-build was
      choking on this missing link to libgimpbase and failing.
      The error returned by the linker though was a bit amiss.
      
      Fixes:
      > gimp-test-clipboard.o: In function `test_clipboard_copy_callback':
      > tools/gimp-test-clipboard.c:419: undefined reference to `g_file_get_contents'
      > collect2: error: ld returned 1 exit status
      
      (cherry picked from commit 0865e9db)
      14614969
  5. 11 Jul, 2018 1 commit
  6. 23 Jun, 2018 1 commit
  7. 16 Jun, 2018 1 commit
    • Salamandar's avatar
      Fix Python files: · 15075932
      Salamandar authored
      * Prefer python2 to python that may point on python3 on modern installs.
      * Fix indent/spaces consistency.
      
      (cherry picked from commit 22657012)
      15075932
  8. 15 Jun, 2018 2 commits
  9. 04 Jun, 2018 1 commit
  10. 28 May, 2018 1 commit
  11. 27 May, 2018 4 commits
    • Jehan's avatar
      tools: make gimptool memory-managed. · f3de5cd3
      Jehan authored
      The code was basically leaking memory everywhere, and apparently on
      purpose (according to a top comment). Even on short-lived process, not
      properly managing memory is not a good habit, especially if we plan to
      maintain a program for the long run.
      So here are some fixes. I'm sure I must have missed some places (code
      was a mess), and hopefully I broke nothing. But that's good for now. At
      least it is somewhat sane code now.
      f3de5cd3
    • Jehan's avatar
      tools: do not segfault gimptool with source without extension. · 02fc818b
      Jehan authored
      Since commit 58fa3820, gimptool would accept source files with
      non-standard extensions when using known C or C++ compilers. This would
      include source with no extensions at all.
      When this happens, do not try to set a pointer to a non-existing dot
      separator to '\0'. That obviously segfaults.
      02fc818b
    • Jehan's avatar
      tools: clean tabs out of gimptool code. · 355676e7
      Jehan authored
      355676e7
    • 張俊芝's avatar
      Issue #1506: Adds support for source file names with special... · 58fa3820
      張俊芝 authored
      ... characters and non-standard suffixes in gimptool
      58fa3820
  12. 20 May, 2018 1 commit
  13. 18 Apr, 2018 1 commit
  14. 15 Apr, 2018 1 commit
    • Tobias's avatar
      Fix build with vector icons enabled · c5044967
      Tobias authored
      The invert-svg tool was never built so generating the Symbolic-Inverted
      icons failed. Thanks Ell for the hint how to fix this.
      c5044967
  15. 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.
      6ebc3f1b
  16. 07 Apr, 2018 1 commit
  17. 10 Mar, 2018 1 commit
    • 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.
      5893d2dc
  18. 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.
      8d2ae895
  19. 04 Feb, 2018 2 commits
  20. 29 Jan, 2018 2 commits
  21. 28 Jan, 2018 7 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.
      fe3cf080
    • 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, 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
      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
      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, 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
  22. 17 Dec, 2017 5 commits
  23. 30 Nov, 2017 2 commits