1. 11 Jul, 2018 1 commit
  2. 17 Jun, 2018 1 commit
  3. 13 May, 2018 1 commit
  4. 03 May, 2018 1 commit
    • Ell's avatar
      app: cleanly remove log handlers on exit · 2e643e62
      Ell authored
      Remove the log handlers registered in errors_init(), in
      errors_exit(), and call errors_exit() before destroying the Gimp
      instance, since the log handlers depend on it.  This avoids
      segfaulting if a message is logged after destroying the Gimp
  5. 09 Apr, 2018 1 commit
  6. 22 Mar, 2018 1 commit
    • Jehan's avatar
      app: output a dialog to recover images salvaged after a crash. · 25af765f
      Jehan authored
      Since commit d916fedf, GIMP has had the hidden feature to salvage
      images (if possible) during a crash into a backup folder. This commit
      finishes the feature by opening a dialog proposing to try and recover
      the salvaged images.
      This is not perfect yet since it doesn't "remember" the XCF path (in
      case it was a previously saved image). The images open as new unsaved
      and dirty images, but directly from the contents at crash time. For now,
      it is up to people to figure out what they correspond to, if relevant.
  7. 22 Feb, 2018 1 commit
  8. 21 Feb, 2018 1 commit
    • Jehan's avatar
      Bug 793630 - GIMP does not create 'gradients' directory on first run. · 6c932287
      Jehan authored
      I had to shuffle a bit the order of initialization since we were
      creating a folder for the crash logs, as well as one for the backups a
      bit too early. So now I move errors_init() after configuration folder
      creation/migration, and I create both these folders in this function
      (especially since gimp_init_signal_handlers() is run even earlier).
      For this later reason, I also check for backtrace_file and backup_path
      being allocated in gimp_eek() since it is also possible for signals
      happening before errors_init(). In such a case, we will simply bypass
      the GUI error handler (terminal error handler still possible) and the
      backup (anyway there is nothing to backup at this point).
      I could also try to create these 2 directories at the last second, when
      needed. But since we are trying to do the strict minimum during crash
      handling, it is better to do whatever can be done earlier.
  9. 13 Feb, 2018 1 commit
    • Jehan's avatar
      app: when WARNING or CRITICAL debugging are ignored, go to terminal. · 37f99069
      Jehan authored
      Current code was redirecting WARNING and CRITICAL errors to normal
      messaging when the debugging was deactivated (in Preferences). But if
      you deactivate these on purpose, then it means you don't want to get
      annoyed by small pop-ups either.
      This commit makes them directly displayed in terminal, as they used to
      before, when debugging is deactivated.
  10. 12 Feb, 2018 5 commits
    • Jehan's avatar
      app: auto-backup of current work-in-progress images during a crash. · d916fedf
      Jehan authored
      As previously explained, this was the next and logical step after
      debugging. At the very end, just before exiting the process, let's
      attempt to save all unsaved (i.e. "dirty") images. Of course we try to
      do so as backup files in the config directory (once again, this would
      be better under $XDG_CACHE_HOME/GIMP/ though) because we must not touch
      the originals.
      Currently we only have some automatic saving, but we don't warn yet that
      backups were made. Also we don't keep track of the original paths for
      later recovery hints. Proposed recovery would be worth being done at
      next start of GIMP when we detect files in the backup directory (with a
      typical "What should we do with these?" dialog).
      Also it is to be noted that it is not a 100%-sure system. While testing
      various test cases, I had many cases where the images were successfully
      saved, but others when the backup failed (in particular when playing
      with double freeing). I'm not sure if this is because of some memory
      allocation during XCF saving or some other issue which could be improved
      later (hopefully).
    • Jehan's avatar
    • Jehan's avatar
      app: add GIMP_MESSAGE_BUG_WARNING + GIMP_MESSAGE_BUG_CRITICAL severity. · 77ed4761
      Jehan authored
      Since a few commits, I don't generate the traces anymore in errors.c but
      delay this to gui-message.c and rely on the message severity to decide
      whether or not generating traces.
      Unfortunately none of the current severities are properly describing
      this new type of messages. Even GIMP_MESSAGE_ERROR is used everywhere in
      our code NOT for actual programming bug, but often for data errors
      (which are not bugs but proper messages and should obviously not prompt
      a debug trace).
    • Jehan's avatar
      app: handle GEGL WARNING and CRITICAL with the new debugging GUI. · 5d200c2c
      Jehan authored
      It is not always very useful since GEGL makes heavy use of threads, and
      therefore a backtrace of the main thread for an error on another thread
      is mostly useless. But that's a start. I am still improving.
      I was holding on non-GIMP messages until now because we don't have as
      much control on them, and for some errors, they may be huge. For
      instance, the bug told by Massimo in bug 792787, comment 22, generates
      hundreds of thousands (and even millions for big enough polygons) of
      errors. But I can now allow these to pass since previous commit when I
      now only display a few errors, and then redirect remaining errors to
      Also get rid of gimp_third_party_message_log_func() and instead make
      gimp_message_log_func() handle correcly non-GIMP messages by keeping
      their domain.
    • 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.
  11. 09 Feb, 2018 1 commit
  12. 08 Feb, 2018 4 commits
    • Jehan's avatar
      app: make debugging preference finer-grained than a boolean. · d5a67cb1
      Jehan authored
      Replacing the boolean property "generate-backtrace" by an enum
      "debug-policy". This property allows one to choose whether to debug
      WARNING, CRITICAL and FATAL (crashes), or CRITICAL and FATAL only, or
      only FATAL, or finally nothing.
      By default, a stable release will debug CRITICAL and crashes, and
      unstable builds will start debugging at WARNINGs.
      The reason for the settings is that if you stumble upon a reccurring bug
      in your workflow (and this bug is not major enough for data corruption,
      and "you can live with it"), you still have to wait for a new release.
      At some point, you may want to disable getting a debug dialog, at least
      temporarily. Oppositely, even when using a stable build, you may want to
      obtain debug info for lesser issues, even WARNINGs, if you wish to help
      the GIMP project.
      It can be argued though whether the value GIMP_DEBUG_POLICY_NEVER is
      really useful. There is nothing to gain from refusing debugging info
      when the software crashed anyway. But I could still imagine that someone
      is not interested in helping at all. It's sad but not like we are going
      to force people to report. Let's just allow disabling the whole
      debugging system.
    • 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.
    • Jehan's avatar
      app: replace g_on_error_query() and g_on_error_stack_trace() by... · 5de7aab4
      Jehan authored
      ... our own implementation.
      Though the GUI stacktrace is better for most (because it is visible even
      when not run in a terminal), the CLI options are quite useful too and
      may still be preferred by some, in particular developers. So it may as
      well be benefiting from the better implementation. Glib traces are quite
      weak even though they also use gdb and debug info are present (often,
      even though I had these traces, I had to run gdb separately; now it
      won't be necessary in many cases). My traces include more information.
      Note that I didn't implement gimp_print_stack_trace() from previous
      gimp_get_stack_trace() because I cannot allocate a string after some
      types of crash (e.g. segmentation faults). So instead,
      gimp_print_stack_trace() now take care optionally of both cases: either
      allocating a string, or directly pipe to a file descriptor.
    • Jehan's avatar
      app: don't check stack_trace_mode anymore in gimp_get_stack_trace(). · 753f4cf4
      Jehan authored
      These are now parallel concepts. The stack_trace_mode is for the CLI
      option and the check happens on another level already.
  13. 04 Feb, 2018 1 commit
  14. 29 Jan, 2018 1 commit
    • Jehan's avatar
      app: add support for Linux backtrace() API. · 4fd1c6c9
      Jehan authored
      It is nice because when available (Linux only?), it is a lot faster than
      using a dedicated debugger such as GDB or LLDB, and also it allows to
      always have a backtrace, even when no debuggers are installed.
      Unfortunately the output is a lot less detailed, with no file paths, no
      line numbers (even when debug symbols are there), no local values
      printout, etc. It's pretty bare, with function names and the stack
      levels. This is why it is not given priority, and GDB and LLDB are still
      preferred when available.
  15. 28 Jan, 2018 11 commits
    • Jehan's avatar
    • 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.
    • 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.
    • 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.
    • 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
      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.
    • 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.
    • 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.
    • 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.
    • 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
    • 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.
    • 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).
  16. 07 Jun, 2017 1 commit
    • Jehan's avatar
      Bug 774971 - Display errors outputted by GEGL. · b7dd2622
      Jehan authored
      Add a log handler so that GIMP can display errors outputted by GEGL.
      Since third party code may run in threads and we have no control on
      these, we have to be sure GTK+ code is run in a thread-safe way, hence
      the usage of gdk_threads_add_idle_full(). This was the case here for
      GEGL, and handling GEGL logs the same way as other GIMP logs would
      result in crashes.
  17. 20 May, 2015 1 commit
  18. 14 Oct, 2013 1 commit
    • Michael Natterer's avatar
      app,libgimp*: fix includes to follow our include policy · 697572cc
      Michael Natterer authored
      - don't include <gdk-pixbuf/gdk-pixbuf.h> in headers in app/
      - instead, include it in many .c files instead of <glib-object.h>,
        finally acknowledging the fact that app/ depends on gdk-pixbuf almost
      - fix up includes as if libgimpbase depended in GIO, which it soon will
  19. 17 Jan, 2009 1 commit
    • Michael Natterer's avatar
      Change licence to GPLv3 (and to LGPLv3 for libgimp). · d9b5207a
      Michael Natterer authored
      2009-01-17  Michael Natterer  <mitch@gimp.org>
      	* all files with a GPL header and all COPYING files:
      	Change licence to GPLv3 (and to LGPLv3 for libgimp).
      	Cleaned up some copyright headers and regenerated the parsers in
      	the ImageMap plugin.
      svn path=/trunk/; revision=27913
  20. 04 Nov, 2008 1 commit
    • Sven Neumann's avatar
      bumped minimum required version of GLib to 2.18.0. · 4762b734
      Sven Neumann authored
      2008-11-04  Sven Neumann  <sven@sven>
      	* configure.in: bumped minimum required version of GLib to 
      	* INSTALL: document the updated dependency.
      	* app/core/gimp.[ch]: introduced gimp_message_literal(), a 
      	of gimp_message() that takes a literal string.
      	* app/errors.[ch]: removed format arguments from 
      	and gimp_terminate() and let them take a literal string instead.
      	* app/tools/gimptool.[ch]: introduced 
      	a variant of gimp_tool_message() that takes a literal string.
      	* app/actions/documents-commands.c
      	* app/actions/drawable-commands.c
      	* app/actions/edit-commands.c
      	* app/actions/error-console-commands.c
      	* app/actions/file-commands.c
      	* app/actions/gradients-commands.c
      	* app/actions/image-commands.c
      	* app/actions/layers-commands.c
      	* app/actions/palettes-commands.c
      	* app/actions/plug-in-commands.c
      	* app/actions/select-commands.c
      	* app/actions/vectors-commands.c
      	* app/config/gimprc.c
      	* app/core/gimp-modules.c
      	* app/core/gimp-parasites.c
      	* app/core/gimp-templates.c
      	* app/core/gimp-units.c
      	* app/core/gimpchannel.c
      	* app/core/gimpcontainer-filter.c
      	* app/core/gimpdrawable-bucket-fill.c
      	* app/core/gimpimage-convert.c
      	* app/core/gimpimage-merge.c
      	* app/core/gimpimage.c
      	* app/core/gimpimagefile.c
      	* app/core/gimplayer-floating-sel.c
      	* app/core/gimplayer.c
      	* app/core/gimpselection.c
      	* app/dialogs/convert-dialog.c
      	* app/dialogs/dialogs.c
      	* app/dialogs/palette-import-dialog.c
      	* app/dialogs/preferences-dialog.c
      	* app/dialogs/quit-dialog.c
      	* app/dialogs/stroke-dialog.c
      	* app/display/gimpdisplayshell-dnd.c
      	* app/file/file-open.c
      	* app/file/file-procedure.c
      	* app/file/file-save.c
      	* app/file/file-utils.c
      	* app/gegl/gimpcurvesconfig.c
      	* app/gegl/gimplevelsconfig.c
      	* app/gui/gui-message.c
      	* app/gui/gui.c
      	* app/gui/session.c
      	* app/paint/gimpbrushcore.c
      	* app/paint/gimpclone.c
      	* app/paint/gimpheal.c
      	* app/paint/gimpperspectiveclone.c
      	* app/paint/gimpsourcecore.c
      	* app/pdb/gimppdb-utils.c
      	* app/pdb/gimpprocedure.c
      	* app/plug-in/gimpplugin-message.c
      	* app/plug-in/gimpplugin.c
      	* app/plug-in/gimppluginmanager-restore.c
      	* app/plug-in/gimppluginprocedure.c
      	* app/text/gimptextlayer.c
      	* app/tools/gimp-tools.c
      	* app/tools/gimpaligntool.c
      	* app/tools/gimpblendtool.c
      	* app/tools/gimpbrightnesscontrasttool.c
      	* app/tools/gimpbucketfilltool.c
      	* app/tools/gimpcolorbalancetool.c
      	* app/tools/gimpcolorpickertool.c
      	* app/tools/gimpcurvestool.c
      	* app/tools/gimpdesaturatetool.c
      	* app/tools/gimpeditselectiontool.c
      	* app/tools/gimpforegroundselecttool.c
      	* app/tools/gimpfreeselecttool.c
      	* app/tools/gimpgegltool.c
      	* app/tools/gimphuesaturationtool.c
      	* app/tools/gimpimagemaptool-settings.c
      	* app/tools/gimpiscissorstool.c
      	* app/tools/gimplevelstool.c
      	* app/tools/gimpmeasuretool.c
      	* app/tools/gimppainttool.c
      	* app/tools/gimpposterizetool.c
      	* app/tools/gimpselectiontool.c
      	* app/tools/gimpsourcetool.c
      	* app/tools/gimpthresholdtool.c
      	* app/tools/gimptransformtool.c
      	* app/tools/gimpvectortool.c
      	* app/widgets/gimpactionview.c
      	* app/widgets/gimpcontrollerlist.c
      	* app/widgets/gimpcontrollers.c
      	* app/widgets/gimpdataeditor.c
      	* app/widgets/gimpdevices.c
      	* app/widgets/gimpdnd-xds.c
      	* app/widgets/gimperrordialog.c
      	* app/widgets/gimphelp.c
      	* app/widgets/gimpitemtreeview.c
      	* app/widgets/gimppdbdialog.c
      	* app/widgets/gimpsettingsbox.c
      	* app/widgets/gimpvectorstreeview.c
      	* app/widgets/gimpwidgets-utils.c
      	* app/xcf/xcf-load.c
      	* tools/pdbgen/pdb/convert.pdb
      	* tools/pdbgen/pdb/edit.pdb
      	* tools/pdbgen/pdb/floating_sel.pdb
      	* tools/pdbgen/pdb/image.pdb: use the _literal variants for
      	g_set_error(), gimp_message() and gimp_tool_message().
      	* app/pdb/convert-cmds.c
      	* app/pdb/edit-cmds.c
      	* app/pdb/floating-sel-cmds.c
      	* app/pdb/image-cmds.c: regenerated.
      svn path=/trunk/; revision=27548
  21. 13 Jun, 2007 1 commit
  22. 26 Jan, 2007 1 commit
    • Tor Lillqvist's avatar
      Make the handling of console output make more sense Win32. Should mostly · 92cdceed
      Tor Lillqvist authored
      2007-01-26  Tor Lillqvist  <tml@novell.com>
      	Make the handling of console output make more sense Win32. Should
      	mostly fix #400927.
      	* app/app_procs.c (app_exit): Drop the Win32 "This console window
      	will close in ten seconds" message from here.
      	(app_run): Drop the call to FreeConsole() from here. GIMP is built
      	as a GUI executable on Windows, and in case we do open a fresh
      	console window in main() (see below), we shouldn't then
      	immediately close it here.
      	* app/errors.c (errors_init): Drop printing the "You can mimize
      	this window, but don't close it" message on Win32 from here.
      	* app/main.c (gimp_open_console_window): New Win32-only
      	function. If either stdout or stderr are unconnected, open a new
      	console window and connect stdout and/or stderr to it as
      	needed. Set the console title to "GIMP output. You can minimize
      	this window, but don't close it." Register an atexit function that
      	waits for the user to close the console window.
      	(wait_console_window): New Win32-only function. Registered as an
      	atexit function when GIMP has opened a new console window. Prompts
      	the user to type any character to close the window.
      	(main, gimp_show_version): Always call gimp_open_console_window()
      	in the unstable version. As the "This is a development version of
      	GIMP. Debug messages may appear here" message says, one point of
      	the unstable version is that debug messages should be visible, so
      	I think it makes sense to always see them in an unstable
      	version. In stable versions, call gimp_open_console_window() only
      	if options that cause output that the user wants to see were
      	given, like --help and --version.
      svn path=/trunk/; revision=21781
  23. 09 Dec, 2006 1 commit