1. 16 Sep, 2018 3 commits
    • Ell's avatar
    • Ell's avatar
      tools: add performance-log-viewer.py and driver · 3601c918
      Ell authored
      performance-log-viewer.py is a viewer for GIMP performance logs.
      The viewer is made up of two parts: a sample-selection area at the
      top, and an information area at the bottom.
      
      The sample-selection area visualizes the sampled variables and
      markers using a simultaneous set of plots, and displays the
      currently selected samples.  Samples can be selected directly
      through the sample-selection area, or by other means, such as
      searching for all samples satisfying a certain condition, or
      containing a certain function.
      
      The information area shows global information stored in the log, as
      well as information specific to the currently selected samples,
      including variable listing and statistics, full backtrace, and
      profile/call-graph information.
      
      Note that performance-log-viewer.py takes its input from STDIN,
      like the rest of the performance-log tools, and is therefore
      suitable for use as part of a pipeline.  For standalone use, the
      performance-log-viewer driver is also included, which takes the log
      file as a command-line argument, and processes it through an
      appropriate pipeline before feeding it to the viewer.
      3601c918
    • Ell's avatar
      tools: add performance-log-deduce.py · 7e186f3e
      Ell authored
      ... which statistically deduces the correct thread states based on
      backtrace address frequency, fixing local inaccuracies.
      7e186f3e
  2. 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
  3. 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
  4. 20 Aug, 2018 1 commit
  5. 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
  6. 11 Jul, 2018 1 commit
  7. 23 Jun, 2018 1 commit
  8. 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
  9. 15 Jun, 2018 2 commits
  10. 04 Jun, 2018 1 commit
  11. 28 May, 2018 1 commit
  12. 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
  13. 20 May, 2018 1 commit
  14. 18 Apr, 2018 1 commit
  15. 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
  16. 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
  17. 07 Apr, 2018 1 commit
  18. 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
  19. 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
  20. 04 Feb, 2018 2 commits
  21. 29 Jan, 2018 2 commits
  22. 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
  23. 17 Dec, 2017 4 commits