Rapidly typing arbitrary letters during swaylock gives me a Bus error and exits swaylock.
The behavior is always reproducable and it never took longer than about 10 seconds to produce it.
(btw, you should change the error message: https://www.youtube.com/watch?v=W9P69WigjIU)
[_sry, i couldn't resist_]
I've noticed this tool. Swaylock definitely needs work.
I'm not able to reproduce this on swaylock version (2016-10-26, branch ""). Are you still able to reproduce this? (I tried 5 times, 30 seconds each time)
I just tested it again and I'm still able to reproduce the error. My current build is from a chechout from 2016-11-17, main branch. "wlc", as a dependency, has been checked out and build at the same date. Everything else are system packages.
To reproduce the error I am pressing with all ten fingers at high speed randomly on the keyboard, but I just use the letter keys, so no special keys, especially you have to avoid pressing enter.
The error is reproducable with the internal keywboards as well as with an external bluetooth keyboard.
I've tried and I'm not able to reproduce the problem. I wonder if it depends on other software or hardware
@kleinreact Will you retest this problem after new commit?
Is it possible to test this with a fuzzer like afl?
I debugged the problem a little bit and found out the following:
The error always appears while executing cairo_paint(window->cairo) (swaylock, line 220), which is reached via the following call trace:
notify_key(...)
-> render(...) // line 210
-> render_color(...) // line 577
-> cairo_paint(...) // line 220
Commenting out line 577 does not solve the problem, but swaylock now crashes with a much more verbose error message:
wl_buffer@17: error 2: error accessing SHM buffer
11/29/16 11:09:21 - [main.c:29] failed to run wl_display_dispatch
Commenting out lines 210-213 solves the problem for me. However I do not have the fancy animations any more. Note that the problem cannot fixed by just using swaylock -u instead.
So it looks to me like something wayland or cairo related. For comparison, here is my current configuration:
swaylock: 0.10-rc1-68-gcd5694f (2016-11-29, branch "HEAD")
wayland: 1.12.0
wayland-protocols: 1.7
cario: 1.14.6
Just to note: personally, I would also be fine with a minmal version of swaylock that does not have any additional rendering at all, but just restricts to the functionality and maybe hides the currently opened windows. However, I don't know how hard it is to archive this with the current setup.
@Lourens-Rich I check out the most recent changes regularly anyway. So I will keep you up to date as soon as something changes.
I just tested the most recent revision, but the error is still there.
However, I also found out that the error only appears, if I am in a multi-screen setup. On a single screen everthing works fine. Maybe that helps for reproduction.
I just found out another condition, which is neccessary for reproduction. The error only appears, if I am in a multi-screen setup, where at least one monitor is scaled and another is not. As soon as I remove the scaling, the error goes away. I tested it under sway version 0.12-rc1-18-gd4aa604.
Most helpful comment
I just found out another condition, which is neccessary for reproduction. The error only appears, if I am in a multi-screen setup, where at least one monitor is scaled and another is not. As soon as I remove the scaling, the error goes away. I tested it under
sway version 0.12-rc1-18-gd4aa604.