Odd Gtk4 "Critical Errors" out of the blue

Desktop
,
1

Need some hints:

I am all sudden found hundredths of those message below been and my application stalled while doing automated tasks over night.
Not sure, last I check on it via x11-vnc remotely all was good running a repeating task (screens turned off on the remote system).
It seams to have happened just at the time I disconnected from x1-vnc.
It recovered without re-starting the app but resetting the task and restarting.
First time I see this happening, but also first time running this over over and remote checking.
May there be any connection to this?

This is Gtk4 on X11 – it seam still quite buggy to me. Never had an issue a like with Gtk3.

Main those:

gtk_settings_get_for_display: assertion 'GDK_IS_DISPLAY (display)' failed
 Gtk-CRITICAL **: 08:22:24.789: _gtk_settings_get_style_cascade: assertion 'GTK_IS_SETTINGS (settings)' failed
Gtk-CRITICAL **: 08:22:24.789: gtk_settings_get_for_display: assertion 'GDK_IS_DISPLAY (display)' failed
Gtk-CRITICAL **: 08:22:24.789: gtk_root_get_display: assertion 'GTK_IS_ROOT (self)' failed
Gtk-CRITICAL **: 08:22:24.789: _gtk_settings_get_style_cascade: assertion 'GTK_IS_SETTINGS (settings)' failed

....
(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: gtk_settings_get_for_display: assertion 'GDK_IS_DISPLAY (display)' failed

(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: _gtk_settings_get_style_cascade: assertion 'GTK_IS_SETTINGS (settings)' failed

(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: gtk_root_get_display: assertion 'GTK_IS_ROOT (self)' failed

(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: gtk_settings_get_for_display: assertion 'GDK_IS_DISPLAY (display)' failed

(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: _gtk_settings_get_style_cascade: assertion 'GTK_IS_SETTINGS (settings)' failed

(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: gtk_root_get_display: assertion 'GTK_IS_ROOT (self)' failed

...


(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: _gtk_settings_get_style_cascade: assertion 'GTK_IS_SETTINGS (settings)' failed

(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: gtk_root_get_display: assertion 'GTK_IS_ROOT (self)' failed

(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: gtk_settings_get_for_display: assertion 'GDK_IS_DISPLAY (display)' failed

(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: _gtk_settings_get_style_cascade: assertion 'GTK_IS_SETTINGS (settings)' failed

(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: gtk_root_get_display: assertion 'GTK_IS_ROOT (self)' failed

(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: gtk_settings_get_for_display: assertion 'GDK_IS_DISPLAY (display)' failed

(gxsm4:1199865): Gtk-CRITICAL **: 08:22:24.789: _gtk_settings_get_style_cascade: assertion 'GTK_IS_SETTINGS (settings)' failed

Gtk-CRITICAL **: 08:22:24.784: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
2

Those critical warnings are usually the result of a missing display connection and a failed initialisation in the application you’re using.

3

But can/should??? that happen while the app is running and X11 is up?
Anything “pulling” the “display connection” when screens are off and remove connections are on/off?
I am not sure if x11-vnc is doing anything odd.
And it just kept working again after I reconnected via another x11-vnc connection.
Currently on via x11-vnc again and hesitating to disconnect as a job is running!

I am looking for insights here as this is important to know for me.

4

It can happen if the display connection is lost and the application doesn’t immediately terminate.

5

Terminate? Well no – X11 is/was up at all times.

I only disconnected via x11-vnc.
It seam to stall at that point.

When I reconnected this morning the app was up and responsive as I could restart a task. But found all those messages and the previous task been uncompleted as if the event look was on hold/frozen, not sure.

6

Sorry, I don’t use X11 or VNC, so I can’t help you there.

I can only tell you what those messages mean in the context of a GTK application.

7

Ok thanks. Need to test some what more to understand and avoid this.

I just tested it again but could not reproduce it immediately at least.

Any knows better solutions to temporary connect to a running system and application remotely and not disturb anything a like?

8

Set the environment variable G_DEBUG=fatal-criticals, then get a stack trace, then report the issue to the application’s developers.

1 Like