Bug#934790: atril: sometimes prints GLib error message when exiting
On Wed, 14 Aug 2019 at 23:42:04 +0000, brian m. carlson wrote:
> (atril:308857): GLib-CRITICAL **: 23:34:21.398: g_source_set_ready_time: assertion 'source->priv != NULL' failed
>
> This does not always occur, but occurs most of the time when invoked
> with a PDF file from the command line.
This indicates a bug in either atril or some library that it uses. It
is operating on a GSource pointer that is no longer valid, most likely
a leftover pointer to a GSource object that has already been freed. This
is undefined behaviour. If it is indeed a use-after-free, then it could
equally well be acting on some other arbitrary region of memory that
happens to have been allocated where the GSource used to be, which could
have any result, up to and including a security vulnerability.
GLib is trying to be nice to you by making an effort to detect this class
of programming error, logging a warning, and recovering as well as it can,
instead of just crashing. If you would prefer applications to crash under
such circumstances (which is often a useful way to debug what they or
their libraries are doing wrong, but is more destructive for the users
of those applications), please run them with G_DEBUG=fatal-criticals
in the environment, or use g_log_set_always_fatal() to make critical
warnings fatal.
With hindsight, GLib critical warnings should probably have been fatal
(caused an abort() or SIGTRAP) by default, like their equivalents in
libdbus and in glibc's malloc machinery, but it would be highly disruptive
to make that change globally at this stage.
> If you don't think this message is worth fixing, you can ask the glib2.0
> maintainer to compile with G_DISABLE_CHECKS to suppress this warning
This would almost certainly make atril segfault when
g_source_set_ready_time() tried to dereference the NULL source->priv
pointer of the invalid GSource that it has been given. If that's what
you want, G_DEBUG=fatal-criticals or g_log_set_always_fatal() would have
the same practical result but with more ability to diagnose what is wrong.
> or to patch GLib not to produce warnings to stderr in g_return_*_if_fail.
Please do not request this, it will not be implemented. Logging warnings
to stderr is an entirely valid response to undefined behaviour. (So
is crashing, which is what will often happen in practice when the
undefined behaviour is not straightforward to detect, like passing an
invalid pointer to a string function like g_strcmp0() or glibc strcmp();
and so is making demons fly out of your nose[1].)
smcv
[1] https://en.wikipedia.org/wiki/Undefined_behavior
Reply to: