Translate GLib critical assertions mc into error messages

[zaytsev]

The root cause of #4576 (visual glitches in the editor) turned out to be GLib critical asserts caused by wrong usage of GLib function (calling it on a NULL pointer). These asserts are printed on the standard streams and usually swallowed by Midnight Commander. Probably many graphical artifacts have those as a root cause.

GLib people say that there is a way to capture these assertions:

With the initial proviso that critical warnings always indicate application bugs, and should always be fixed rather than ignored or hidden…

Critical warnings are logged using GLib’s standard logging framework (g_log_structured()), so you can intercept them by calling g_log_set_writer_func() and providing your own log writer function. It will have to handle all log messages from GLib (e.g. all calls to g_debug(), g_message(), g_warning(), etc.), not just critical warnings. The default writer function is g_log_writer_default() and you can see what it does here.

You could, for example, set the writer function to (the built-in) g_log_writer_journald() to send all the messages to the systemd-journal rather than stdout/stderr.

​https://gitlab.gnome.org/GNOME/glib/-/issues/3459#note_2208789

I'm not familiar with the error handling infrastructure of mc, but it does show red error messages from time to time. It would be good to translate GLib critical assertions (and maybe something else, like warnings? depending on how much, how useful and how annoying it is) to red error boxes in mc, so that instead of being ignored or causing graphical glitches they can be noticed and fixed.

[ossi]

message boxes would be a terrible user experience. users should not be confronted with uncontrollable barrages of crap caused by the application's bugs.

journald would be better in this regard, but no-one would even notice it. i suppose one could print a single "there were internal errors; check the log" message to stderr on exit.

[andrew_b]

Replying to zaytsev:

g_log_structured()
g_log_set_writer_func()
g_log_writer_default()

glib >= 2.50

You could, for example, set the writer function to (the built-in) g_log_writer_journald() to send all the messages to the systemd-journal rather than stdout/stderr.

glib >= 2.50 too. Fortunately, there are some distros withowt crapd.

[zaytsev]

message boxes would be a terrible user experience. users should not be confronted with uncontrollable barrages of crap caused by the application's bugs.

Well, it's not known how many of those are there in the code in the first place. Maybe there are none (even though I doubt it).

As a developer I'd like to have them pop up just like the immediate crashes of the sanitizers, so that I can connect it with what I just did. Also, I'm running mc instances for weeks if not months in a row, so when I exit and get a log full of those, it will be very hard to debug, because I literally exercised every single feature in the meantime.

But maybe warning boxes should be made optional in the first place with the default of being disabled. This way users won't get visual corruption, because the assertions are captured, but also if it can be enabled, causes of strange behaviors are much easier to identify and developers can just run it with warning translation AND alerting enabled by default.

[zaytsev]

Fortunately, there are some distros withowt crapd.

macOS comes to mind ;-)

glib >= 2.50

We can write a translator with conditional compilation for glib >= 2.50, without having to bump glib, if we decide to do it in the first place.

I'm more interested in the warning infrastructure we have in mc, but I don't have time to look into it - still pending replies to other tickets. Not sure we even have something like an internal error queue.

Anyways, as we have learned, swallowing glib internal assertions is no good. If we don't have infrastructure to translate and don't want to build it, maybe we can just (optionally) crash at least.

I wanted to create this ticket to save this point. Couldn't find any other one on the subject.