Multi instances of one application cause cairo-dock to be hanging
Closed this issue · 14 comments
Steps to reproduce
- Run cairo-dock in opengl mode,
cairo-dock -L -o - Run any application with three instances, and you can see them in a group of the dock.
- Click the sub dock, switch window between them "rapidly"(it is a little hard to reproduce.), finally the dock hangs.
Digs
Problem file
src/implementations/cairo-dock-egl.c
static void _container_end_draw (GldiContainer *pContainer)
{
EGLSurface surface = pContainer->eglSurface;
EGLDisplay *dpy = s_eglDisplay;
eglSwapBuffers (dpy, surface);
}Issues may relate to the problem
- eglSwapBuffers blocks in wayland when it's wl_surface_frame event is stolen.
I am not sure it's the same problem, but maybe related
Backtrace
#0 0x00007ffff7178f6f in __GI___poll (fds=fds@entry=0x7fffffffa6c0, nfds=nfds@entry=0x1, timeout=timeout@entry=0xffffffff) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007ffff614cb5e in poll (__timeout=0xffffffff, __nfds=0x1, __fds=0x7fffffffa6c0) at /usr/include/bits/poll2.h:39
#2 wl_display_poll (display=0x5555555b1ad0, events=0x1) at ../wayland-1.22.0/src/wayland-client.c:1914
#3 wl_display_dispatch_queue (queue=<optimized out>, display=<optimized out>) at ../wayland-1.22.0/src/wayland-client.c:1987
#4 wl_display_dispatch_queue (display=0x5555555b1ad0, queue=0x555555adbe80) at ../wayland-1.22.0/src/wayland-client.c:1960
#5 0x00007ffff071fe65 in dri2_wl_swap_buffers_with_damage () at ../mesa-23.3.3/src/egl/drivers/dri2/platform_wayland.c:1576
#6 0x00007ffff0710938 in dri2_swap_buffers () at ../mesa-23.3.3/src/egl/drivers/dri2/egl_dri2.c:1958
#7 0x00007ffff070800d in eglSwapBuffers () at ../mesa-23.3.3/src/egl/main/eglapi.c:1443
#8 0x00007ffff72a7aac in _on_expose (pWidget=pWidget@entry=0x555555b31aa0 [GtkWindow], pCairoContext=<optimized out>, pDock=0x555555bcf490)
at /usr/src/debug/cairo-dock-core-wayland-git/cairo-dock-core-wayland-git/src/gldit/cairo-dock-dock-factory.c:114
#9 0x00007ffff74c56cd in _gtk_marshal_BOOLEAN__BOXED
(closure=0x5555559965d0, return_value=0x7fffffffaa20, param_values=0x7fffffffaab0, marshal_data=<optimized out>, invocation_hint=<optimized out>, n_param_values=<optimized out>)
at gtk/gtkmarshalers.c:84
#10 0x00007ffff776f3c3 in _gtk_marshal_BOOLEAN__BOXED
(marshal_data=0x0, invocation_hint=<optimized out>, param_values=0x7fffffffaab0, n_param_values=0x2, return_value=0x7fffffffaa20, closure=0x5555559965d0) at gtk/gtkmarshalers.c:70
#11 gtk_widget_draw_marshaller (closure=0x5555559965d0, return_value=0x7fffffffaa20, n_param_values=0x2, param_values=0x7fffffffaab0, invocation_hint=<optimized out>, marshal_data=0x0)
at ../gtk/gtk/gtkwidget.c:951
#12 0x00007ffff7eda6c0 in g_closure_invoke (closure=0x5555559965d0, return_value=0x7fffffffaa20, n_param_values=0x2, param_values=0x7fffffffaab0, invocation_hint=0x7fffffffaa00)
at ../glib/gobject/gclosure.c:832
#13 0x00007ffff7f08a36 in signal_emit_unlocked_R.isra.0
(node=node@entry=0x7fffffffaba0, detail=detail@entry=0x0, instance=instance@entry=0x555555b31aa0, emission_return=emission_return@entry=0x7fffffffac20, instance_and_params=instance_and_pa
rams@entry=0x7fffffffaab0) at ../glib/gobject/gsignal.c:3980
#14 0x00007ffff7ef9335 in signal_emit_valist_unlocked
(instance=instance@entry=0x555555b31aa0, signal_id=signal_id@entry=0x46, detail=detail@entry=0x0, var_args=var_args@entry=0x7fffffffad00) at ../glib/gobject/gsignal.c:3625
#15 0x00007ffff7ef9c77 in g_signal_emit_valist (instance=0x555555b31aa0, signal_id=0x46, detail=0x0, var_args=var_args@entry=0x7fffffffad00) at ../glib/gobject/gsignal.c:3355
#16 0x00007ffff7ef9d34 in g_signal_emit (instance=instance@entry=0x555555b31aa0, signal_id=<optimized out>, detail=detail@entry=0x0) at ../glib/gobject/gsignal.c:3675
#17 0x00007ffff7781ae3 in gtk_widget_draw_internal (widget=0x555555b31aa0 [GtkWindow], cr=0x555555b18d00, clip_to_size=<optimized out>) at ../gtk/gtk/gtkwidget.c:7077
#18 0x00007ffff778c862 in gtk_widget_render (widget=0x555555b31aa0 [GtkWindow], window=<optimized out>, region=<optimized out>) at ../gtk/gtk/gtkwidget.c:17610
#19 0x00007ffff7628c8b in gtk_main_do_event (event=0x7fffffffaf60) at ../gtk/gtk/gtkmain.c:1844
#20 gtk_main_do_event (event=<optimized out>) at ../gtk/gtk/gtkmain.c:1691
#21 0x00007ffff7370b77 in _gdk_event_emit (event=0x7fffffffaf60) at ../gtk/gdk/gdkevents.c:73
#22 _gdk_event_emit (event=0x7fffffffaf60) at ../gtk/gdk/gdkevents.c:67
#23 0x00007ffff7382b02 in _gdk_window_process_updates_recurse_helper (window=0x555555b18b60 [GdkWaylandWindow], expose_region=<optimized out>) at ../gtk/gdk/gdkwindow.c:3874
#24 0x00007ffff7387158 in gdk_window_process_updates_internal (window=0x555555b18b60 [GdkWaylandWindow]) at ../gtk/gdk/gdkwindow.c:4020
#25 0x00007ffff7387375 in gdk_window_process_updates_with_mode (recurse_mode=<optimized out>, window=<optimized out>) at ../gtk/gdk/gdkwindow.c:4215
Thank you for looking into this! I experienced similar issues before, but was never able to catch it in a debugger. Based on your backtrace, I now have an idea for at least a workaround. My initial thought was that the compositor closing the subdock popup was triggering it, but the issue you linked can be the real problem. Just to clarify:
- Can you check which version of Mesa you're using? It seems that the issue you link should be fixed in version 23.1 or later
- In cases when the dock does not freeze, does the subdock disappear?
- Are you triggering this with scrolling or clicking?
I am using Mesa 23.3, and the issue is indeed fixed. I just notice the backtrace is similar to that from the link.
When the dock doesn't freeze, the sub dock disappears.
Both scrolling and clicking could reproduce the issue.
So far I cannot reproduce anymore -- for me it was always much less predictable. But I think it is a race condition between closing the subdock and rendering to it. I have an idea to test this further, but it will take some more time. Just to confirm, does this happen when running without EGL? (cairo-dock -c)
A crude workaround is patching Wayfire so that it does not close popups:
diff --git a/src/view/xdg-shell.cpp b/src/view/xdg-shell.cpp
index 243c7140..664b023a 100644
--- a/src/view/xdg-shell.cpp
+++ b/src/view/xdg-shell.cpp
@@ -47,13 +47,13 @@ wayfire_xdg_popup::wayfire_xdg_popup(wlr_xdg_popup *popup) : wf::view_interface_
{
// 'toplevel' popups are responsible for closing their popup tree when the parent loses focus.
// Note: we shouldn't close nested popups manually, since the parent popups will destroy them as well.
- this->on_keyboard_focus_changed = [=] (wf::keyboard_focus_changed_signal *ev)
+/* this->on_keyboard_focus_changed = [=] (wf::keyboard_focus_changed_signal *ev)
{
if (ev->new_focus != popup_parent->get_surface_root_node())
{
this->close();
}
- };
+ }; */
}
on_surface_commit.set_callback([&] (void*) { commit(); });
Your workaround works, though it may not be the best choice.
Thank you very much!
Just to confirm, does this happen when running without EGL? (cairo-dock -c)
No, it doesn't happen with cairo mode. As shown from the backtrace before, it hung in eglSwapBuffers function.
But is this an issue for wayfire?
I am wondering whether I need to report the problem to Meas team, since the problem and that issue in my origin report are too alike.
Hi,
could you further test the following?
https://github.com/dkondor/egl_popup_test -- this is a simplified test case that freezes reliably for me (click on the grey / black popup, and it results that the color changes in the red window stop)
https://github.com/dkondor/cairo-dock-core/tree/egl_popup_freeze -- this might be a workaround for Cairo-Dock for this problem
Thank you!
https://github.com/dkondor/egl_popup_test -- this is a simplified test case that freezes reliably for me (click on the grey / black popup, and it results that the color changes in the red window stop)
I can reproduce in the wayfire without the previous crude patch, I will report to mesa as soon as possible.
https://github.com/dkondor/cairo-dock-core/tree/egl_popup_freeze -- this might be a workaround for Cairo-Dock for this problem
It does fix the problem, thanks a lot.
Hi,
could you also test this branch:
https://github.com/dkondor/cairo-dock-core/tree/egl_experimental ?
I think it might be a better way to workaround the issue.
Thank you!
I'm sorry, my Arch Linux network is experiencing issues, I won't have a try until my network is restored.
Edit:
It looks smoother and some little problems disappears now, thank you!
Thank you again for testing, I'll close this now, but let me know if the issue resurfaces.