lock circumvented (broken) when issuing setxkbmp and xkbcomp and fast typing

rdiaz02 commented 6 months ago

I'm submitting a…

[x] Bug
[ ] Feature Request
[ ] Other (Please describe in detail)

Current Behavior

When resuming from suspend, and if I also alter the keyboard map on resume, if I type quickly (say, both hands, several keypresses per second), the lock is broken.

I use i3lock with xss-lock as follows:

xss-lock --transfer-sleep-lock -- i3lock --nofork &

If I type much more slowly or nothing at all, generally the lock is not broken.

Expected Behavior

The lock is not broken when resuming from sleep, regardless of typing.

As a comparison, some other lockers do not show this behavior. I've tested it with xtrlock, slock, and xsecurelock (all launched as i3lock) and xscreen-saver (launched as xss-lock -- xscreensaver-command --lock &), and none of them I could break this way.

Reproduction Instructions

I only see this happen with an automatic monitor configuration setup I have, that chooses the right monitor on resume. But the monitor configuration per se is irrelevant; the crucial feature is a combination of setxkbmap and xkbcomp.

I can reproduce the problem with this minimal setup.

Ensure i3lock runs on suspend:

xss-lock --transfer-sleep-lock -- i3lock --nofork &

Have a script kbd-config in /usr/lib/systemd/system-sleep/ . kbd-config is

#!/bin/sh

## based on https://askubuntu.com/a/1318782
## https://unix.stackexchange.com/a/697316

PATH=/sbin:/usr/sbin:/bin:/usr/bin

case "$1" in
    pre)
    ;;
    post)
    export DISPLAY=:0
    sudo -u THE_USER_NAME -i /THE_USER_HOME/keym.sh
    ;;
esac

exit 0

Where keym.sh is

#!/bin/bash

setxkbmap -layout es -option ctrl:nocaps
xkbcomp -synch -w0 ~/tmp/some_xkb_dump.txt $DISPLAY

(I do not think the actual XKB keymap matters much. I've used a couple of different ones with success. Attaching one: some-xkb-dump.txt. I do not think that that the layout is set to 'es' matters either, nor the ctrl:nocaps option).

From the command line issue systemctl suspend. The screen locks and then the computer suspends.
Once the computer is suspended, press the button to resume and type very quickly. The screen gets unlocked.
If you issued 1. from a terminal that you still have opened, you will probably see this too
```
[i3lock] xkb_x11_keymap_new_from_device failed
```

Environment

Output of i3lock --version:

i3lock version: 2.14.1

stapelberg commented 6 months ago

Can you also provide the output of i3lock --debug with/without the XKB change from your system please? Be sure to redact the password from the output before sharing.

rdiaz02 commented 6 months ago

Attached. In all cases, "[some random character typed]" refers to characters that I was typing randomly as per step 4. in the bug report.

When i3lock breaks: debug-XKB-change-i3lock-breaks.txt

When no XKB change and i3lock does not break debug-NO-XKB-change-NO-i3lock-breaks.txt

Edit Adding two additional debug logs:

I change de XKB but i3lock does not break (because I wait around 16 seconds after resuming before touching the keyboard; I resume, wait for the screen to show i3lock's all-gray screen, count a few more seconds, and then start slowly typing, and at that moment the green circle shows up, etc, so I have to introduce the password). debug-XKB-change-no-break.txt
I change XKB and I do not need to type furiously: it breaks as soon as I introduce the first character. debug-XKB-change-breaks-at-first-type.txt

stapelberg commented 6 months ago

Can you check if pull request https://github.com/i3/i3lock/pull/353 fixes the issue for you? Thanks.

rdiaz02 commented 6 months ago

Yes, it does fix the issue for me. (I still see the "[i3lock] xkb_x11_keymap_new_from_device failed", but it does not unlock).

stapelberg commented 6 months ago

Great, thanks for confirming. I merged the immediate fix for now.

Can you clarify if the xkb_x11_keymap_new_from_device error message only happens when you change XKB layout while i3lock is running, or can you get into a state where i3lock does not even start? (the keymap is loaded at startup and when it changes)

Can you file a separate bug for what needs to be fixed please?

rdiaz02 commented 6 months ago

Can you clarify if the xkb_x11_keymap_new_from_device error message only happens when you change XKB layout while i3lock is running,

I've only noticed xkb_x11_keymap_new_from_device when I change XKB layout while i3lock is running. (At the risk of being redundant, though, note that even if xkb_x11_keymap_new_from_device happens that does not necessarily mean i3lock breaks: with the fix I get the xkb_x11_keymap_new_from_device , and I also got it before the fix even when i3lock did not break: see file https://github.com/i3/i3lock/files/14893717/debug-XKB-change-no-break.txt , above: https://github.com/i3/i3lock/issues/351#issuecomment-2041079229).

can you get into a state where i3lock does not even start?

When I issue systemct suspend i3lock does get started. As I mentioned in step 3. of my original report, "The screen locks and then the computer suspends." But this is all happening before XKB layout changes.

I am not sure what you are asking, though. If it is about what happens immediately after resume, I cannot tell. My monitor always has a lag after resuming/starting, so for the first few seconds after I press the start key (resume) and when I start typing, I cannot tell what is going on on the monitor as nothing is being visibly displayed.

Can you file a separate bug for what needs to be fixed please?

I don't know of an additional bug that needs to be fixed. Is this the xkb_x11_keymap_new_from_device ?

I think I am not following you.

stapelberg commented 6 months ago

Ok, I looked into this some more and I think I understand now.

To reproduce the problem, I found it sufficient to run keym.sh repeatedly, no suspend needed.

Looking at the X11-level trace, I think the problem is that i3lock gets a notification about the changed keymap, but while fetching the keymap details, the keymap changes again (due to the second command in keym.sh), which results in an X11 error.

So, to answer my own question: these are spurious errors, not persistent errors somehow related to the keymap. No further fixes needed.

BTW: I also triggered a crash in gnome-shell while reproducing the problem:

gdb $ bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=5, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007f17b56ae8a3 in __pthread_kill_internal (signo=5, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007f17b565c8ee in __GI_raise (sig=sig@entry=5) at ../sysdeps/posix/raise.c:26
#3  0x000055cdb4674b86 in dump_gjs_stack_on_signal_handler (signo=5) at ../src/main.c:467
#4  0x00007f17b565c9a0 in <signal handler called> () at /lib64/libc.so.6
#5  g_log_structured_array (log_level=log_level@entry=G_LOG_LEVEL_ERROR, fields=fields@entry=0x7fff4e6afee0, n_fields=4) at ../glib/gmessages.c:556
#6  0x00007f17b5f40edc in g_log_default_handler
    (log_domain=log_domain@entry=0x7f17b5b0d023 "Mtk", log_level=log_level@entry=6, message=message@entry=0x55cdb6973480 "Received an X Window System error.\nThis probably reflects a bug in the program.\nThe error was 'BadValue (integer parameter out of range for operation)'.\n  (Details: serial 37367 error_code 2 request_c"..., unused_data=unused_data@entry=0x0) at ../glib/gmessages.c:3284
#7  0x00007f17b5f41180 in g_logv (log_domain=0x7f17b5b0d023 "Mtk", log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, args=args@entry=0x7fff4e6b0040) at ../glib/gmessages.c:1392
#8  0x00007f17b5f41463 in g_log
    (log_domain=log_domain@entry=0x7f17b5b0d023 "Mtk", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7f17b5b0d0f0 "Received an X Window System error.\nThis probably reflects a bug in the program.\nThe error was '%s'.\n  (Details: serial %ld error_code %d request_code %d (%s) minor_code %d)\n  (Note to programmers: nor"...) at ../glib/gmessages.c:1461
#9  0x00007f17b5b0b5be in display_error_event (error=0x7fff4e6b01d0, xdisplay=0x55cdb4f40570) at ../mtk/mtk/mtk-x11-errors.c:116
#10 mtk_x_error (xdisplay=0x55cdb4f40570, error=0x7fff4e6b01d0) at ../mtk/mtk/mtk-x11-errors.c:139
#11 0x00007f17b5522acb in _XError (dpy=dpy@entry=0x55cdb4f40570, rep=rep@entry=0x55cdb566d790) at /usr/src/debug/libX11-1.8.7-1.fc39.x86_64/src/XlibInt.c:1503
#12 0x00007f17b5522bdf in handle_error (dpy=dpy@entry=0x55cdb4f40570, err=0x55cdb566d790, in_XReply=in_XReply@entry=1) at /usr/src/debug/libX11-1.8.7-1.fc39.x86_64/src/xcb_io.c:211
#13 0x00007f17b5524bca in _XReply (dpy=0x55cdb4f40570, rep=0x7fff4e6b0380, extra=2, discard=0) at /usr/src/debug/libX11-1.8.7-1.fc39.x86_64/src/xcb_io.c:798
#14 0x00007f17b557254e in _XkbHandleGetMapReply (xkb=0x55cdb4fc3800, dpy=0x55cdb4f40570) at xkb/XKBGetMap.c:557
#15 XkbGetMapChanges (dpy=dpy@entry=0x55cdb4f40570, xkb=0x55cdb4fc3800, changes=changes@entry=0x7fff4e6b03e0) at xkb/XKBGetMap.c:870
#16 0x00007f17b5573660 in XkbRefreshKeyboardMapping (event=event@entry=0x7fff4e6b0590) at xkb/XKBBind.c:377
#17 0x00007f17b590a0cb in meta_keymap_x11_handle_event (xevent=0x7fff4e6b0590, keymap_x11=0x55cdb51bb5a0) at ../src/backends/x11/meta-keymap-x11.c:602
#18 meta_keymap_x11_handle_event (xevent=0x7fff4e6b0590, keymap_x11=0x55cdb51bb5a0) at ../src/backends/x11/meta-keymap-x11.c:575
#19 meta_seat_x11_translate_event (xevent=0x7fff4e6b0590, seat=<optimized out>) at ../src/backends/x11/meta-seat-x11.c:2044
#20 meta_backend_x11_handle_event (xevent=0x7fff4e6b0590, backend=0x55cdb4f38ea0) at ../src/backends/x11/meta-event-x11.c:71
#21 handle_host_xevent (event=0x7fff4e6b0590, backend=0x55cdb4f38ea0) at ../src/backends/x11/meta-backend-x11.c:434
#22 x_event_source_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../src/backends/x11/meta-backend-x11.c:488
#23 0x00007f17b5f3be5c in g_main_dispatch (context=0x55cdb4dd6cd0) at ../glib/gmain.c:3476
#24 g_main_context_dispatch_unlocked (context=0x55cdb4dd6cd0) at ../glib/gmain.c:4284
#25 0x00007f17b5f96f18 in g_main_context_iterate_unlocked.isra.0 (context=0x55cdb4dd6cd0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4349
#26 0x00007f17b5f3d447 in g_main_loop_run (loop=0x55cdb532e640) at ../glib/gmain.c:4551
#27 0x00007f17b58e5b2a in meta_context_run_main_loop (context=<optimized out>, error=0x7fff4e6b0be0) at ../src/core/meta-context.c:514

Feel free to reproduce/report it if you feel adventurous :)

rdiaz02 commented 6 months ago

No further fixes needed.

Ah, great. Issue solved then. Thanks.

I also triggered a crash in gnome-shell. (...) Feel free to reproduce/report it if you feel adventurous :)

I think I am not feeling that adeventurous ;-) And I think I've never used gnome-shell so this would be way too adventurous for me.

i3 / i3lock