On 64-bit, all seems fine, but when building to 32-bit (at least Windows
32-bit), G_GUINT64_FORMAT is defined to "%llu" while time_t is a long
int. So it doesn't match and the compiler complains:
> warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'time_t' {aka 'long int'}
Let's cast to (guint64) to make sure the type always match.
As suggested by LRN, change gimp_sigfatal_handler() on Windows to
dstinguish between fatal and non-fatal exceptions so we don't abort on
each minor hickup.
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.
Using g_get_user_data_dir() is maybe right on Win32 (for this roaming
vs. local directory logics), but not on Unix-like systems, where we end
up trying to write in the data directory (usually not even supposed to
be writable by applications).
Also while at it, I replace g_get_prgname() by PACKAGE_NAME. It turns
out that this function returns NULL, maybe because of the init order.
Actually ideally, this file should rather go under:
$XDG_CACHE_HOME/GIMP/<version>/
But last we discussed this, it was decided that files should not spread
too much (though I still disagree!).
... 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.
SIGABRT is definitely a fatal error, at least in GIMP context. It is
used by g_assert() and more generally by abort().
Actually I am a bit unsure about the difference of gimp_terminate() and
gimp_fatal_error(). The former mostly depends on whether we used
--debug-handlers or not, which reads "Enable non-fatal debugging signal
handlers". But the way we handle them, the list of signals handled by
gimp_terminate() seem to always end up fatal as well, anyway. So either
we should *really* make them non-fatal (I could imagine that SIGTERM or
SIGINT indeed could be better handled for instance), or we should just
get rid of this terminate/fatal_error differentiation which seems
totally artificial and non-existing in the current code.
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.
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.
- 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
2008-10-13 Sven Neumann <sven@gimp.org>
* app/Makefile.am
* app/signals.[ch]: new files with code split out of main.c.
* app/main.c: changed accordingly.
svn path=/trunk/; revision=27270
Luca Bacci