A log error can have a NULL domain (apparently equivalent to "" default
domain, according to g_log_set_handler() docs and we even explicitly
list the NULL domain in the log_domains array in app/gimp-log.c.
Yet our log handler was not expecting such possibility and was running a
g_str_has_prefix() on NULL. Not sure why it aborted there. It might be
because outputting a new warning inside the warning handler did not go
well. Anyway this seems to fix our side of the bug #5358. The main fix
will likely be on GEGL side (UMFPACK_ERROR_out_of_memory error).
... which set/remove a GLIB log handler for all domains used by
GIMP.
Use the new functions in errors.c, instead of using
g_log_set_handler() directly.
The call to "gimp-xcf-save" was not updated to the new API using a
drawable array and a GFile.
Also for the drawable array, do not actually create it as anyway this is
a dummy argument (so far XCF saving does not even look at this argument
and just re-check the selected drawables).
Previously we were only passing this information on the debug dialog
when debugging warnings and criticals. Now it will also have the
information for crashes, hence recommending people to update their GIMP
instead of reporting bugs on old versions.
Turn all ID param specs into object param specs (e.g. GimpParamImageID
becomes GimpParamImage) and convert between IDs and objects in
gimpgpparams.c directly above the the wire protocol, so all of app/,
libgimp/ and plug-ins/ can deal directly with objects down to the
lowest level and not care about IDs.
Use the actual object param specs for procedure arguments and return
values again instead of a plain g_param_spec_object() and bring back
the none_ok parameter.
This implies changing the PDB type checking functions to work on pure
integers instead of IDs (one can't check whether object creation is
possible if performing that check requires the object to already
exist).
For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is
not involved in automatic object creation magic at the protocol
level. Added wrappers which still say gimp_foo_is_valid() and take the
respective objects.
Adapted all code, and it all becomes nicer and less convoluted, even
the generated PDB wrappers in app/ and libgimp/.
gimp_eek(): simply increase gimp->busy so XCF saving calling
gimp_set_busy() and gimp_unset_busy() won't call the GUI layer and do
whatever windowing system calls to set busy cursors.
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
instance.
This function is unsafe during signal handling. And in any case, when
printing to stderr, I don't think we need to convert to UTF-8. Quite the
contrary, the system encoding may be more appropriate.
Since commit d916fedf92, 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.
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.
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.
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).
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).
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
stderr.
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.
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.
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.
... 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.
... 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.
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.
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.
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.
* 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.
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.
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.
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.
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.
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.
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).
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.
Looks like they were forgotten so messages from libs went to stdout
instead of being routed through the log handlers, which would show
them in a dialog, or in the error console.
- 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
globally
- fix up includes as if libgimpbase depended in GIO, which it soon will
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
2007-06-13 Sven Neumann <sven@gimp.org>
* app/errors.[ch]: added errors_exit() and unset the Gimp
reference. Errors may occur after the Gimp object has been finalized.
* app/app.c (app_run): call errors_exit().
svn path=/trunk/; revision=22768
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
2006-10-09 Michael Natterer <mitch@gimp.org>
Added message severities and make sure all messages are routed
through a central function, so redirecting to the error console or
stderr work again:
* app/core/core-enums.[ch]: added enum GimpMessageSeverity { INFO,
WARNING, ERROR }.
* app/core/gimp.[ch] (gimp_message)
(gimp_message_valist): added severity parameter. Changed
"GimpProgress *progress" parameter to "GObject *handler", where
"handler" can be either a GimpProgress, a GtkWidget or NULL.
* app/core/gimp-gui.[ch] (gimp_show_message): ditto. Honor
--console-messages again. Always dispatch to the GUI message
handler first if it exists.
* app/gui/gui-message.[ch]: pass severity parameters around.
(gui_message_error_dialog): if "handler" is a progress, dispatch
the message to it first. If it is a widget (and *not* a progress),
use a GtkMessageDialog on top of that widget's toplevel. Fall
back to the usual GimpErrorDialog otherwise.
* app/core/gimpprogress.[ch] (gimp_progress_message): added
severity parameter. Also added boolean return value to the virtual
function so it can decide to fail if it can't handle the message.
* app/display/gimpdisplay.c: implement GimpProgress::message() and
redirect the message to GimpDisplayShell.
* app/display/gimpdisplayshell-progress.c: implement
GimpProgress::message() and redirect the message to GimpStatusbar
if it is not an error and if the status bar is visible.
* app/display/gimpstatusbar.[ch]: implement GimpProgress::message(),
but fail on messages that contain a newline. Show the right icons
for the message severities (work in progress).
* app/display/gimpdisplayshell.[ch]: removed
gimp_display_shell_message() and its _valist() variant.
* app/widgets/gimperrorconsole.[ch]: show the right icons for the
message severities.
* app/widgets/gimpthumbbox.c (gimp_thumb_box_progress_message):
return TRUE to swallow all messages.
* app/widgets/gimpwidgets-utils.[ch]: removed
gimp_show_message_dialog(). Added gimp_get_message_stock_id().
* app/errors.c
* app/actions/edit-commands.c
* app/actions/error-console-commands.c
* app/actions/file-commands.c
* app/actions/select-commands.c
* app/actions/text-editor-commands.c
* app/actions/vectors-commands.c
* app/core/gimpimage-convert.c
* app/core/gimpimagefile.c
* app/dialogs/convert-dialog.c
* app/dialogs/file-open-dialog.c
* app/dialogs/file-open-location-dialog.c
* app/dialogs/file-save-dialog.c
* app/dialogs/palette-import-dialog.c
* app/dialogs/stroke-dialog.c
* app/display/gimpdisplayshell-dnd.c
* app/pdb/gimppdb.c
* app/plug-in/gimpplugin.c
* app/tools/gimpimagemaptool.c
* app/tools/gimptool.c
* app/tools/gimpvectortool.c
* app/widgets/gimpactionview.c
* app/widgets/gimpcontrollerlist.c
* app/widgets/gimppdbdialog.c
* app/widgets/gimpvectorstreeview.c
* app/xcf/xcf-load.c
* app/xcf/xcf-save.c
* app/xcf/xcf.c
* tools/pdbgen/pdb/brush.pdb
* tools/pdbgen/pdb/gradient.pdb
* tools/pdbgen/pdb/image.pdb
* tools/pdbgen/pdb/message.pdb
* tools/pdbgen/pdb/palette.pdb: added severity parameter to
gimp_message() calls. Convert all calls to
gimp_show_message_dialog() and gimp_display_shell_message() to
gimp_message(). Also converted some more g_message() calls.
* app/pdb/brush_cmds.c
* app/pdb/gradient_cmds.c
* app/pdb/image_cmds.c
* app/pdb/message_cmds.c
* app/pdb/palette_cmds.c: regenerated.
Jehan