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

Nested sway crashes randomly #5055

Closed
brandsimon opened this issue Feb 29, 2020 · 10 comments · Fixed by swaywm/wlroots#2048
Closed

Nested sway crashes randomly #5055

brandsimon opened this issue Feb 29, 2020 · 10 comments · Fixed by swaywm/wlroots#2048

Comments

@brandsimon
Copy link

brandsimon commented Feb 29, 2020

I run a nested sway and sometimes it crashes. It happens usually when there is no interaction (I am on another workspace in the host sway).
I use this config:

exec xfce4-terminal

Here is a debug log: http://sprunge.us/8mSZHv

My sway version is sway version 1.4.

Steps to reproduce:
I basically do nothing.
I start sway with the config and pipe the debug log into a file.
Sometimes I change to the workspace with the nested sway to see if it crashed, then go back to another workspace.
I am using an uptodate Arch Linux with intel graphics card.

The crash is also reproducible when I start firefox, claws-mail or anyithing else in sway.

@ascent12
Copy link
Member

Please post a backtrace of sway.

coredumpctl gdb sway
...
(gdb) bt
<copy this bit>
(gdb) q

@brandsimon
Copy link
Author

@ascent12
There is no backtrace. My last backtrace from sway is over a week ago (the libinput assertion bug).
The exit code from sway is 0.
Here is another log where I didnt even had an exec something:
http://sprunge.us/5wVo79

@RedSoxFan
Copy link
Member

That debug log shows something going horribly wrong.

  • 21 keyboards get added in less than a second
  • On the 21st, the following in logged. Likely due to running out of memory.
file descriptor expected, object (163), message keymap(uhu)
2020-03-02 05:45:36 - [backend/wayland/backend.c:57] Failed to dispatch remote Wayland display
2020-03-02 05:45:36 - [backend/wayland/backend.c:57] Failed to dispatch remote Wayland display
  • 107 keyboards are removed

@brandsimon
Copy link
Author

I think this happens when I change tty. (I do this quite often sometimes)

@brandsimon
Copy link
Author

brandsimon commented Mar 2, 2020

This is totally related to a tty switch.The crash occurs after 6 switches.
Every time I switch to another tty and back, there are even more keyboards returned with swaymsg -t get_inputs.
This can be seen in the log: http://sprunge.us/zg83Tk
Interesting is, that there are no duplicate pointer devices.

I have another problem with firefox in a nested sway (which I did not report because I only encountered it with firefox):
Very rarely one key press seam to get duplicated, I press a and there are like 20 as
If this situation happens, this will happen with every key press.
It would be interesting if this could be fixed with fixing this bug.
When this happens the next time, I will do a swaymsg -t get_inputs there.

emersion added a commit to emersion/wlroots that referenced this issue Mar 2, 2020
Previously, each time a wl_seat.capabilities event was received the
Wayland backend created new input devices. It now only does so the first
time.

Input devices are now destroyed when the cap is removed.

Closes: swaywm/sway#5055
@emersion
Copy link
Member

emersion commented Mar 2, 2020

Can you try this patch? swaywm/wlroots#2048

@brandsimon
Copy link
Author

@emersion
Thank you, I tested it today, but it resulted in a coredump after the first tty switch: http://sprunge.us/ezNLTx
Does it help if I compile something with debug symbols?

@brandsimon
Copy link
Author

Sorry for the little information. The coredump happend in the nested sway.
Here is a coredump http://sprunge.us/ueoMpH with a corresponding debug log http://sprunge.us/DOSGaw

emersion added a commit to emersion/wlroots that referenced this issue Mar 3, 2020
Previously, each time a wl_seat.capabilities event was received the
Wayland backend created new input devices. It now only does so the first
time.

Input devices are now destroyed when the cap is removed.

Closes: swaywm/sway#5055
@emersion
Copy link
Member

emersion commented Mar 3, 2020

Ah, sorry about that. Should be fixed now.

@brandsimon
Copy link
Author

@emersion
Great, it seams to work now.
No keyboard / pointer duplication and no crash :)
Thank you very much (to all of you for the great work!)

emersion added a commit to emersion/wlroots that referenced this issue Mar 4, 2020
Previously, each time a wl_seat.capabilities event was received the
Wayland backend created new input devices. It now only does so the first
time.

Input devices are now destroyed when the cap is removed.

Closes: swaywm/sway#5055
emersion added a commit to swaywm/wlroots that referenced this issue Mar 4, 2020
Previously, each time a wl_seat.capabilities event was received the
Wayland backend created new input devices. It now only does so the first
time.

Input devices are now destroyed when the cap is removed.

Closes: swaywm/sway#5055
filips pushed a commit to filips/wlroots that referenced this issue Mar 15, 2020
Previously, each time a wl_seat.capabilities event was received the
Wayland backend created new input devices. It now only does so the first
time.

Input devices are now destroyed when the cap is removed.

Closes: swaywm/sway#5055
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

4 participants