1.0.2 causes segfault on xkb_x11_keymap_new_from_device

[Kodehawa]

Log:

#0 0x00007f6bbc8b8615 in raise () at /usr/lib/libc.so.6
#1 0x00007f6bbc8b86a0 in <signal handler called> () at /usr/lib/libc.so.6
#2 0x00007f6bb6ead150 in () at /usr/lib/libxkbcommon-x11.so.0
#3 0x00007f6bb6eae2b4 in xkb_x11_keymap_new_from_device () at /usr/lib/libxkbcommon-x11.so.0
#4 0x00007f6bb6f8cb89 in () at /usr/lib/libQt5XcbQpa.so.5
#5 0x00007f6bb6f863cf in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) () at /usr/lib/libQt5XcbQpa.so.5
#6 0x00007f6bb6f86c69 in QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
at /usr/lib/libQt5XcbQpa.so.5
#7 0x00007f6bb6faa54e in () at /usr/lib/libQt5XcbQpa.so.5
#8 0x00007f6bbcf193fc in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#9 0x00007f6bbcf21894 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5

Interestingly, the release notes do note "- Improve the speed of xkb_x11_keymap_new_from_device() on repeated calls in the same xkb_context().". This crash happens if I spam keys or I use a macro that does many keypresses at once, so that might be a little broken :)

Let me know if you need anything else. This happens on any and all programs, that was just a qt5 example.

[Kodehawa]

In a more (maybe) funny turns of events, 1.0.2 is also unbuildable for me, so I can't get you debug symbols. Trying to build such results in a test failure:

1/20 libxkbcommon / keysym                           OK             0.01s
2/20 libxkbcommon / keymap                           OK             0.02s
3/20 libxkbcommon / filecomp                         OK             0.02s
4/20 libxkbcommon / context                          OK             0.02s
5/20 libxkbcommon / rules-file                       OK             0.02s
6/20 libxkbcommon / rules-file-includes              OK             0.01s
7/20 libxkbcommon / stringcomp                       OK             0.03s
8/20 libxkbcommon / buffercomp                       OK             0.03s
9/20 libxkbcommon / log                              OK             0.01s
10/20 libxkbcommon / atom                             OK             0.08s
11/20 libxkbcommon / utf8                             OK             0.01s
12/20 libxkbcommon / state                            OK             0.01s
13/20 libxkbcommon / keyseq                           OK             0.04s
14/20 libxkbcommon / rulescomp                        OK             0.05s
15/20 libxkbcommon / compose                          OK             0.03s
16/20 libxkbcommon / utils                            OK             0.01s
17/20 libxkbcommon:python-tests / symbols-leak-test   OK             0.04s
18/20 libxkbcommon / x11                              OK             0.02s
19/20 libxkbcommon / registry                         OK             0.02s
20/20 libxkbcommon:python-tests / tool-option-parsing FAIL           4.88s (exit status 1)

EDIT: Nevermind, I could build it by just skipping tests :P EDIT 2: I got a crash with the recompiled one, but the crash isn't any useful still :(

[whot]

20/20 libxkbcommon:python-tests / tool-option-parsing FAIL 4.88s (exit status 1)

you'll have the path to the meson testlogs at the end which will provide you with some more info about what's failing. Please attach that file, thanks.

[Kodehawa]

Attached as requested.

[Kodehawa]

Full test log generated by meson.

Might be worth saying that on 1.0.1 I haven't gotten that segfault again, while on 1.0.2 I get it every few minutes or if I just start spamming keys :)

[bluetech]

@Kodehawa thanks for the report. I'll need a few more details to locate where the segfault is happening.

Which keymap are you using?

Which window manager or app are you using (i3)?

What does bashing the keys mean? (Are you switching layouts or updating the keymap in any way, or just pressing keys)?

The test failure seems unrelated, so in your local build, can you reproduce the issue when running ./build/xkbcli-interactive-x11? With that you should be getting debug symbols.

[Kodehawa]

There's no crash on ./build/xkbcli-interactive-x11, but while trying to reproduce it, it crashed KWin :)

#0  0x00007f1a74049615 in raise () at /usr/lib/libc.so.6
#1  0x00007f1a740496a0 in <signal handler called> () at /usr/lib/libc.so.6
#2  0x00007f1a6e63d150 in  () at /usr/lib/libxkbcommon-x11.so.0
#3  0x00007f1a6e63e2b4 in xkb_x11_keymap_new_from_device () at /usr/lib/libxkbcommon-x11.so.0
#4  0x00007f1a6e71cb89 in  () at /usr/lib/libQt5XcbQpa.so.5
#5  0x00007f1a6e7163cf in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) () at /usr/lib/libQt5XcbQpa.so.5
#6  0x00007f1a6e716c69 in QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
at /usr/lib/libQt5XcbQpa.so.5
#7  0x00007f1a6e73a54e in  () at /usr/lib/libQt5XcbQpa.so.5
#8  0x00007f1a746aa3fc in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#9  0x00007f1a746b2894 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5
#10 0x00005650a20e74d8 in main(int, char**) (argc=1, argv=0x7ffd68d358b8) at /usr/src/debug/kwin/main_x11.cpp:421

The output of it while reproducing the issue was:

keysyms [ Super_L          ] unicode [  ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
Keymap updated!
keysyms [ Shift_L          ] unicode [  ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ Shift Mod4 ] leds [ ]
keysyms [ Super_L          ] unicode [  ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ Shift ] leds [ ]
Keymap updated!
keysyms [ Super_L          ] unicode [  ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
keysyms [ Super_L          ] unicode [  ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
Keymap updated!
keysyms [ Shift_L          ] unicode [  ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ Shift Mod4 ] leds [ ]
keysyms [ Super_L          ] unicode [  ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ Shift ] leds [ ]
Keymap updated!
Keymap updated!
keysyms [ Shift_L          ] unicode [  ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ Shift Mod4 ] leds [ ]
keysyms [ Super_L          ] unicode [  ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ Shift ] leds [ ]
Keymap updated!
keysyms [ a                ] unicode [ a ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
keysyms [ a                ] unicode [ a ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
keysyms [ s                ] unicode [ s ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
keysyms [ d                ] unicode [ d ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
keysyms [ l                ] unicode [ l ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
keysyms [ k                ] unicode [ k ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
keysyms [ d                ] unicode [ d ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
keysyms [ j                ] unicode [ j ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
keysyms [ s                ] unicode [ s ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
keysyms [ f                ] unicode [ f ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]
Keymap updated!
keysyms [ Shift_L          ] unicode [  ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ Shift Mod4 ] leds [ ]
keysyms [ Super_L          ] unicode [  ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ Shift ] leds [ ]
Keymap updated!
keysyms [ Super_L          ] unicode [  ] layout [ Spanish (Latin American) (0) ] level [ 0 ] mods [ ] leds [ ]

My main layout is latam with an extra US layout that I switch to using Alt + Space. I'm using KDE. Bashing the keys means doing ljksfgdj;olhfgdsgj;afolhk;gjklsfgskfl;djagsfdjl;k :p

Also it crashes any and all KDE/Qt apps, the stacktrace is the same:

updating the keymap in any way

The keymap updates randomly while I press keys according to the output above? EDIT: The double keymap updated! part caused the segfault.

I just got this when I left my computer for a while to make food lol

[XakepSDK]

I got this error when i tried to enable compositor using alt+shif+f12 hotkey I have english and russian languages configured in kde settings for keyboard (shift+alt to switch)

Application: KWinFT (kwin_x11), signal: Segmentation fault

[KCrash Handler]
#4  0x00007ff21cd65150 in  () at /usr/lib/libxkbcommon-x11.so.0
#5  0x00007ff21cd662b4 in xkb_x11_keymap_new_from_device () at /usr/lib/libxkbcommon-x11.so.0
#6  0x00007ff21ce3ab89 in  () at /usr/lib/libQt5XcbQpa.so.5
#7  0x00007ff21ce343cf in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) () at /usr/lib/libQt5XcbQpa.so.5
#8  0x00007ff21ce34c69 in QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5XcbQpa.so.5
#9  0x00007ff21ce5854e in  () at /usr/lib/libQt5XcbQpa.so.5
#10 0x00007ff222dc33fc in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#11 0x00007ff222dcb894 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5
#12 0x0000562d7d136879 in main(int, char**) (argc=<optimized out>, argv=0x7fffd3377188) at /home/user/Desktop/kwinft-git/src/kwin/main_x11.cpp:421
[Inferior 1 (process 16478) detached]

[bluetech]

I released libxkbcommon 1.0.3 with a (possible) fix for this. Since I haven't managed to reproduce or get a non-stripped backtrace yet I'm not sure. Let me know if it still happens with 1.0.3.

[Kodehawa]

The test still doesn't pass. I can't get a non-stripped backtrace myself even when building it with debug symbols. I might need to build qt5-base with debug symbols, but I somehow just can't.

Besides tests, I'll try

I compiled 1.0.3 and installed it. I'll let you know in a few if I get any crashes while using so normally.

[bluetech]

Regarding the test, I looked at your test output but it doesn't make a lot of sense to me. Could it be somehow Python 2 gets used instead of Python 3?

Regarding the debug symbols, let's say you have a meson build directory in ~/libxkbcommon/build, and you built it (even if the test failed). Then you can run the crashing application like this: LD_LIBRARY_PATH=~/libxkbcommon/build my-app and it should include debug symbols then. If you use systemd you can get a stacktrace with the coredumpctl program.

Thanks again for helping debug this.

[Kodehawa]

I don't even have python2 installed :)

Then you can run the crashing application like this: LD_LIBRARY_PATH=~/libxkbcommon/build my-app and it should include debug symbols then.

Didn't know. I'll do this if I get the crash again :o

EDIT: Nevermind, I do have it installed (I just removed it now lol). It only points to python2 though. Output below:

~
(> <); -> python2 --version
Python 2.7.18

~
(^ ^) -> python --version
Python 3.8.6

EDIT 2: I removed python2 completely, and the test still fails.

[Kodehawa]

Just as a note, if the main issue gets fixed on 1.0.3, should I open another issue for the test failing or just keep this one?

[bluetech]

I think a new issue would be good.

[Kodehawa]

3 hours in I haven't seen a single segfault, which is a big improvement from the one segfault every few minutes (at worst) I was seeing before :)

I won't cheer victory until tomorrow with normal computer usage tho :) Thanks!

[quietvoid]

I've found this issue while looking for the cause of a core dump. For me, it happens after the application has been running for a while, and only when using the media keys.

#1  0x00007f3391c3e2b4 xkb_x11_keymap_new_from_device (libxkbcommon-x11.so.0 + 0x42b4)
#2  0x00007f3391d23b89 n/a (libQt5XcbQpa.so.5 + 0x41b89)
#3  0x00007f3391d1d3cf _ZN14QXcbConnection14handleXcbEventEP19xcb_generic_event_t (libQt5XcbQpa.so.5 + 0x3b3cf)
#4  0x00007f3391d1dc69 _ZN14QXcbConnection16processXcbEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5XcbQpa.so.5 + 0x3bc69)
#5  0x00007f3391d41164 n/a (libQt5XcbQpa.so.5 + 0x5f164)
#6  0x00007f339a1fb914 g_main_context_dispatch (libglib-2.0.so.0 + 0x52914)
#7  0x00007f339a24f7d1 n/a (libglib-2.0.so.0 + 0xa67d1)
#8  0x00007f339a1fa121 g_main_context_iteration (libglib-2.0.so.0 + 0x51121)
#9  0x00007f33a3b986e1 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x30e6e1)
#10 0x00007f33a3b3e3fc _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2b43fc)
#11 0x00007f33a3b46894 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2bc894)
#12 0x00005598197e1eb2 n/a (quasselclient + 0xa6eb2)
#13 0x00007f33a34f0152 __libc_start_main (libc.so.6 + 0x28152)
#14 0x00005598197f8e7e _start (quasselclient + 0xbde7e)

I cannot reproduce it consistently, and it only happens to this Qt5 app. Will try 1.0.3 and report back. If I can build from git..

[Kodehawa]

If you're using arch, here's a 1.0.3 PKGBUILD

PKGBUILD.txt -rename to PKGBUILD-

I haven't had a crash yet, so maybe it's good. Would like confirmation from @quietvoid and @XakepSDK tho :)

[quietvoid]

Cheers, didn't consider the official repos. Installed fine. Edit: I meant the PKGBUILD, looks inspired from there :) It was already flagged as out of date.

[Kodehawa]

I'll create a out of date request on the official repos when this is confirmed fixed :P For now I just made that one PKGBUILD.

Edit: I meant the PKGBUILD, looks inspired from there :)

I copied it and changed the commit and the version :p

[quietvoid]

So far so good, for me.

[Kodehawa]

So far so good aswell and it's been 12 hours :)

Might be fixed. If it's not a stretch, mind sharing what you had to do to fix the issue on the code? :)

[bluetech]

1.0.2 had two commits relating to the xkb_x11_keymap_new_from_device function: f41e609bbea8447fc82849a1a6ea0d116189f2f8 and 1bd3b3c7cb52ae77667d45cb46e8b5af3046a8d7. The bigger one is the second, so I looked at it again but it seemed good. So I reviewed the first one carefully and caught this (existing) line in the second hunk:

FAIL_UNLESS(wire_count == 0 || wire_count == syms_length);

I missed it the first time, and I didn't handle the wire_count == 0 case. I guess this case is not so common, but happens with media keys and such; I didn't investigate too much. The fix is 4aed3c6811bfe7be8c4f9d3771a298a5eae7c264.

The lessons are:

• helpers like FAIL_UNLESS and asserts are useful for future-self
• when making changes to existing complex code, always spend some time to understand the full surrounding context
• C is scary :fearful:

[quietvoid]

Safe to say my issue is fixed with 1.0.3.

[Kodehawa]

Looks fixed to me. Also thanks for the explanation, C is scary indeed D:

Up to @bluetech if they wanna close it now, or wait for more confirmations.

[bluetech]

Alright, thanks everyone.