mate-media: gtk_widget_get_frame_clock(): mate-volume-control-applet killed by SIGABRT

[raveit65]

This is one of repeating bugs which occurred very often in fedora in the last years and were reported by users via fedora bug reporting tool. Mostly mate-media and mate-settings-daemon crashes together, because they are connected via libmatemixer, pulseaudio, etc. Related m-s-d issue: https://github.com/mate-desktop/mate-settings-daemon/issues/402 This is a blocker bug which prevent me to switch the applet to in-process build to avoid that the whole panel crashes. No in-process --> no wayland session.

Actual behaviour

Truncated backtrace:
Thread no. 1 (20 frames)
 #6 gtk_widget_get_frame_clock at ../gtk/gtkwidget.c:5875
 #7 gtk_widget_realize at ../gtk/gtkwidget.c:5545
 #8 gtk_widget_map at ../gtk/gtkwidget.c:5049
 #10 gtk_box_forall at ../gtk/gtkbox.c:2678
 #11 gtk_container_map at ../gtk/gtkcontainer.c:3697
 #12 _g_closure_invoke_va at ../gobject/gclosure.c:895
 #15 gtk_widget_map at ../gtk/gtkwidget.c:5051
 #17 gtk_window_map at ../gtk/gtkwindow.c:6335
 #18 _g_closure_invoke_va at ../gobject/gclosure.c:895
 #21 gtk_widget_map at ../gtk/gtkwidget.c:5051
 #23 gtk_window_show at ../gtk/gtkwindow.c:6210
 #25 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3742
 #28 gtk_widget_show at ../gtk/gtkwidget.c:4852
 #30 gtk_tooltip_position at ../gtk/gtktooltip.c:980
 #31 gtk_tooltip_show_tooltip at ../gtk/gtktooltip.c:1050
 #32 tooltip_popup_timeout at ../gtk/gtktooltip.c:1128
 #37 g_main_context_iterate.isra.0 at ../glib/gmain.c:4276
 #39 gtk_main at ../gtk/gtkmain.c:1329
 #40 _mate_panel_applet_factory_main_internal at /usr/src/debug/mate-panel-1.26.3-1.fc38.x86_64/libmate-panel-applet/mate-panel-applet.c:2459
 #41 mate_panel_applet_factory_main at /usr/src/debug/mate-panel-1.26.3-1.fc38.x86_64/libmate-panel-applet/mate-panel-applet.c:2487

Full stacktrace at https://bugzilla.redhat.com/attachment.cgi?id=1977359

Steps to reproduce the behaviour

User info:

What did you do?

Basically nothing. I've just moved mouse over sound icon and tried to change sound with scroll. (Maybe it's related somehow that I've upgraded from 36->38 but not sure how, and previously few versions before)

MATE general version

1.26.x

Package version

mate-media-1.26.1-1.fc38

Linux Distribution

Fedora 38

Link to bugreport of your Distribution (requirement)

https://bugzilla.redhat.com/show_bug.cgi?id=2225265

@mate-desktop/core-team

I am pretty sure that i ran for myself in this issue when moved with mouse over the applet icon. Sometimes it happens, sometimes not.

[lukefromdc]

This is a bug I never, ever see in Debian. All of this could be hardware specific though

[raveit65]

Why hardware specific? I don't see any hints about GPUs in stacktrace. Honestly i got more than 30 reports about this from a lot of user in the last 5 years (since switch to gtk3). All with different hardware? And i got this bug for myself with nvidia and amdgpu. Maybe you don't have a automatic bug reporting tool like AppArmor installed?

[lukefromdc]

Actually, it looks from the stacktrace like the crash may relate to tooltips (EDIT: this one only, there are two more) , so some way of ensuring the tooltip does not get made or is destroyed if the data sent to it is or becomes invalid might be the fix. (EDIT: better to stop bad data from being sent to (by libmatemixer) or else used anywhere in the applet or m-s-d code)

Note that I just got back from a 4 hours each way road trip.

If you get this bug (which if hardware specific and not hardware plug/unplug triggered would depend on sound hardware not video cards), try building the applet with tooltips commented out or disabled in the code and see if that stops the crash. If it does we then have a known offender.

You are thinking of Apport not Apparmor, and no, I don't have it installed. If I am working over Tor someplace I need to be able to deny having been at, I don't want the OS whose images go on all of my machines engaging in any non-Tor activity. I do not even use network time. As a rule I require manual control over every network connection my machines make. I don't think I've had Apport installed in over a decade, but as I recall it only triggered on crashes and I've never had the volume control applet crash in recent memory.

Note that my sound devices rarely change however, and I do not own any Bluetooth audio devices. If this crash is occuring randomly on plugging or unplugging audio devices (which would change tooltip text) it's no surprise I would not see it.

At any rate, all of these 1.26 crashes predate my wayland work, but there is this issue: in current wayland session, if the panel crashes it stays down (not running mate-session-manager which is an xsession manager), and has to be relaunched from terminal. This could cause a user unfamiliar with the terminal to decide they must trash their work and restart the compositor.

[lukefromdc]

Tooltips won't be enough, I'm thinking all three of these are crashes caused by the same bad data on a removed device getting fed to the applet or to m-s-d. If there is also a problem on a device idling, that could be related but that is speculation on my part. The backend audio device handling (in libmatemixer) is a part of the code I have yet to work with.

[lukefromdc]

See https://github.com/mate-desktop/libmatemixer/issues/39

[raveit65]

This issue i caused by mouse-over the icon, not by unplug a usb device like in your link. Description is different. Note, i didn't forward all bug reports from fedora bugreport tool about mate-media-applet. They are more. I am waiting for user answers than i will forward them. I can't imaging that i will be able to switch the applet to in-process with so many open crashes for fedora. It's a different if you use 2 or 3 boxes for your own or if you maintain a desktop for a distribution. I am responsible for a desktop from lot of fedora users The main problem is that beside from crashing the panel all those issues will crash m-s-d too, in result other features like eg. hidpi scaling are failing too. You can restart the whole session. Building the applet in-process makes the desktop currently really unstable. Hopefully someone from the team can fix those issues....

[lukefromdc]

I probably cannot fix them myself due to inability to duplicate the crash. Mousing over triggers the tooltip, so that particular crash might be bad data fed to the tooltip. On my box I can mouse over the icon all I want and it never crashes. Not only that, I have zero experience with that part of the code, so to fix it without being able to duplicate the issue is probably impossible unless I can find something simply by analyzing the code

Obviously distros in which any applet is unstable are going to have to build that applet out-of-process until it is fixed, note that not being able to use the volume control applet is not a bar to using the rest of MATE on wayland if the other applets are built in-process. We need to find out if mate-volume-control itself also crashes on any of this, thougn in that case it would not take the panel down.

Also-can you duplicate these crashes on wayland, or only on X11? If not, we could rename the in-process applet for wayland only, with the X11 applet staying out of process until a better fix is found.

[raveit65]

Looks like the same issue in debian. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971783

Gtk:ERROR:../../../../gtk/gtkwidget.c:5871:gtk_widget_get_frame_clock: assertion failed: (window != NULL)
Bail out! Gtk:ERROR:../../../../gtk/gtkwidget.c:5871:gtk_widget_get_frame_clock: assertion failed: (window != NULL)

[raveit65]

Also-can you duplicate these crashes on wayland, or only on X11?

No, i use wayland-session only for short PR testings. Caja windows can't be moved. This prevent me to test our applications whole the day in wayland.

[raveit65]

If not, we could rename the in-process applet for wayland only, with the X11 applet staying out of process until a better fix is found

Might be a solution if nothing other helps and the team (including me) is not able to fix the issues.

[lukefromdc]

There is some chance reason that with wayland client-side decorations in Caja the window cannot be moved, in months I have not been able to find it. Nemo and Nautilus windows can be moved. They use GtkApplicationWindow, Pluma does not and it also can be moved, GtkInspector doesn't show any obvious difference. Something must be telling wayfire not to move the CSD window

Switching to server-side decorations in ~/.config/wayfire.ini makes all windows movable but decorations must then be themed from inside ~/.config/wayfire.ini with not a lot of options, that's how I have been using it. This line under coredoes it: preferred_decoration_mode = server Also left-click over any part of a window in wayfire will move it, and right-click will resize it.

[lukefromdc]

In the Debian bug report we have this: (mate-volume-control-status-icon:1761): Gtk-WARNING **: 16:04:20.142: Calling gtk_widget_realize() on a widget that isn't inside a toplevel window is not going to work very well. Widgets must be inside a toplevel container before realizing them.

EDIT: This is in the status-icon (which is in a GtkPlug), so the icon should be inside a GtkPlug. If gtk_widget_realize doesn't like being called on a popup window (e.g. the dock), we might need to change that or not use gtk_widget_realize. If we are getting that on the icon on an out-of-process icon that is odd. Maybe trying to update the dock while it is hidden is doing this?

On a Pluma string search I did not find gtk_widget_realize anywhere in mate-media's source so it might be in the tray or in GTK itself that we are calling this

[lukefromdc]

Also showing

(mate-settings-daemon:1249): GLib-GObject-CRITICAL **: 16:04:20.686: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

(mate-settings-daemon:1249): Gdk-CRITICAL **: 16:04:20.686: gdk_window_get_scale_factor: assertion 'GDK_IS_WINDOW (window)' failed

which suggest we are trying to work on a window that does not exist. If this happens on scrolling it suggests an attempt common to the status icon and the applet to update the popped down dock and something going wrong with that e.g. the dock getting destroyed, then an attempt to update it.

[lukefromdc]

I am now suggesting that anyone running a wayland session and getting this issue temporarily remove the volume control applet from the panel and add a launcher for mate-volume-control in it's place. This of course can also be done if the applet is built out of process for stability in x11 sessions.