Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Activating a view from cairo-dock crashes wayfire #772

Closed
dkondor opened this issue Oct 8, 2020 · 6 comments
Closed

Activating a view from cairo-dock crashes wayfire #772

dkondor opened this issue Oct 8, 2020 · 6 comments
Labels

Comments

@dkondor
Copy link
Contributor

dkondor commented Oct 8, 2020

Steps to reproduce:

  1. Build and run cairo-dock from this branch: https://github.com/dkondor/cairo-dock-core/tree/wayland_egl
  2. Start wayfire and cairo-dock (cairo-dock -o -L)
  3. Start any app (gnome-calculator in my example)
  4. Minimize it
  5. Right click on the icon
  6. From the right click menu, click on the magnifying glass icon (see screenshot)

Expected result: app is restored and activated
Actual result: wayfire crashes (see below for stacktrace)

In this case, cairo-dock is using the activate request of wlr-foreign-toplevel-management.

The crash does not happen if left clicking on the application icon (app is restored and activated) and also does not happen with wf-dock -- both of these methods use the same interface. The crash happens on master without my changes to the foreign toplevel protocol.

cairo-dock-activate-crash

Output from wayfire:

wayfire: ../types/xdg_shell/wlr_xdg_surface.c:364: void handle_xdg_surface_commit(struct wlr_surface *): Assertion `false' failed.
EE 08-10-20 12:38:37.817 - [src/main.cpp:244] Fatal error: Fatal error(SIGABRT)
EE 08-10-20 12:38:37.865 - #1  signal_handler(int) ../src/main.cpp:245
EE 08-10-20 12:38:38.040 - #2  killpg ??:?
EE 08-10-20 12:38:38.178 - #3  __GI_raise ../sysdeps/unix/sysv/linux/raise.c:51 (discriminator 3)
EE 08-10-20 12:38:38.317 - #4  __GI_abort /build/glibc-2ORdQG/glibc-2.27/stdlib/abort.c:81
EE 08-10-20 12:38:38.454 - #5  __assert_fail_base /build/glibc-2ORdQG/glibc-2.27/assert/assert.c:89
EE 08-10-20 12:38:38.629 - #6  __assert_fail ??:?
EE 08-10-20 12:38:38.641 - #7  handle_xdg_surface_commit ../types/xdg_shell/wlr_xdg_surface.c:366
EE 08-10-20 12:38:38.655 - #8  surface_commit_pending ../types/wlr_surface.c:430
EE 08-10-20 12:38:38.669 - #9  surface_commit ../types/wlr_surface.c:502
EE 08-10-20 12:38:38.677 - #10 ffi_call_unix64 ??:?
EE 08-10-20 12:38:38.684 - #11 ffi_call ??:?
EE 08-10-20 12:38:38.694 - #12 wl_closure_invoke /home/dkondor/program/wayland/src/connection.c:1020
EE 08-10-20 12:38:38.703 - #13 wl_client_connection_data /home/dkondor/program/wayland/src/wayland-server.c:432
EE 08-10-20 12:38:38.711 - #14 wl_event_loop_dispatch /home/dkondor/program/wayland/src/event-loop.c:1027
EE 08-10-20 12:38:38.721 - #15 wl_display_run /home/dkondor/program/wayland/src/wayland-server.c:1349
EE 08-10-20 12:38:38.750 - #16 main ../src/main.cpp:406
EE 08-10-20 12:38:38.885 - #17 __libc_start_main ../csu/libc-start.c:344
EE 08-10-20 12:38:38.924 - #18 ?? ??:0
EE 08-10-20 12:38:38.927 - [EGL] command: eglMakeCurrent, error: EGL_BAD_DISPLAY (0x3008), message: "eglMakeCurrent"
EE 08-10-20 12:38:38.927 - [render/egl.c:431] eglMakeCurrent failed
wayfire: ../render/gles2/renderer.c:35: struct wlr_gles2_renderer *gles2_get_renderer_in_context(struct wlr_renderer *): Assertion `wlr_egl_is_current(renderer->egl)' failed.
EE 08-10-20 12:38:38.927 - [src/main.cpp:244] Fatal error: Fatal error(SIGABRT)
@soreau
Copy link
Member

soreau commented Oct 8, 2020

What call is cairo-dock making in this case?

@dkondor
Copy link
Contributor Author

dkondor commented Oct 8, 2020

zwlr_foreign_toplevel_handle_v1_activate()

zwlr_foreign_toplevel_handle_v1_activate()

But the crash does not happen instantly. Actually, it does not happen at all if I set a breakpoint at this line and single step or even if I just continue after the break. It still happens if I run it in a debugger without setting a breakpoint.

@ammen99
Copy link
Member

ammen99 commented Oct 8, 2020

This seems to be a race condition, and hitting this assert would usually mean a bug in wlroots. Have you tried running with ASAN to rule out that Wayfire corrupts the memory?

@dkondor
Copy link
Contributor Author

dkondor commented Oct 8, 2020

Just tried it, ASAN does not report any errors related to this.

I get the following error, but I think it is unrelated:

=================================================================
==24012==ERROR: AddressSanitizer: odr-violation (0x000000d58720):
  [1] size=56 'vtable for wf::touch::gesture_action_t' ../subprojects/wf-touch/src/touch.cpp
  [2] size=56 'vtable for wf::touch::gesture_action_t' ../subprojects/wf-touch/src/touch.cpp
These globals were registered at these points:
  [1]:
    #0 0x5c5810  (/usr/local/bin/wayfire+0x5c5810)
    #1 0x7fc10aada68d  (/usr/local/lib/x86_64-linux-gnu/wayfire/libmove.so+0x7568d)

  [2]:
    #0 0x5c5810  (/usr/local/bin/wayfire+0x5c5810)
    #1 0xa25a9d  (/usr/local/bin/wayfire+0xa25a9d)

==24012==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global 'vtable for wf::touch::gesture_action_t' at ../subprojects/wf-touch/src/touch.cpp
==24012==ABORTING

Telling it to ignore this, i only see memory leaks reported if terminated normally, but not anything if the crash is triggered.

@dkondor
Copy link
Contributor Author

dkondor commented Oct 8, 2020

I looked into this a bit more:

  • the process sending the signal that triggers the crash (client in surface_commit()) seems to be cairo-dock
  • I can also reproduce this with opening multiple apps and trying to switch between them with the magnifying glass icon
  • I cannot reproduce this on sway when switching between apps

@dkondor
Copy link
Contributor Author

dkondor commented Nov 29, 2020

Fixed in wlroots: swaywm/wlroots#2454

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants