xkbcommon
potential problem in FindInterpForKey
Greetings, I recently started getting segfaults when using kitty via rdp. When I ran it via gdb and asked for a backtrace, the last function called appeared to be from libxkbcommon0; so I grabbed a fresh copy here and replaced my package-derived copy and tried again. When next I ran it via gdb, it told me the offending piece of code was at line 416 of xkbcomp/keymap.c. My impression, having read the function, was that perhaps the simpler calloc in the else might be safer, so I dropped a #if 0 around the else if () from line 405 to 422; since doing so I have had no more segmentation faults. As as result, I hypothesize that if someone more knowledgeable looks, there may prove to be an incorrect assumption in the realloc(). I hope you are doing well.
This was Debian unstable, I got segfaults with versions 1.12.3 and 1.7.0 using the debian package, then compiled my own 1.13 from the github release followed by HEAD. In all cases I received a segmentation fault when starting my terminal emulator as mentioned above.
Could you provide your keymap? Use xkbcomp -xkb $DISPLAY /tmp/keymap.xkb if xkbcli dump-keymap > /tmp/keymap.xkb does not work.
Could you point the commit that the lines refer to? It does not seem to be linked to FindInterpForKey, contrary to the issue’s title.
Is there a best way I may provide the keymap dump? It is fairly large (1794 lines).
I need only the xkb_keycodes section if my comment above is right and #943 fixes it. In this case, paste the dump into <details> tag.
If this is really about FindInterpForKey, I need the commit. The best is if you could use a link in this repo to the corresponding lines at the corresponding commit (i.e. a permalink).
I am seeing b09aa7c dated 2025-09-24, titled "Drop the key name LUT after compilation" as the time when this segment of code was modified.
You are absolutely right though, I managed to thoroughly misread the file, the function I modified is UpdateDerivedKeymapFields.
The following is the xkb_keycodes section, my apologies if it is also obnoxiously long:
xkb_keycode section
xkb_keycodes "xfree86+aliases(qwerty)" {
minimum = 8;
maximum = 255;
<LVL5> = 8;
<ESC> = 9;
<AE01> = 10;
<AE02> = 11;
<AE03> = 12;
<AE04> = 13;
<AE05> = 14;
<AE06> = 15;
<AE07> = 16;
<AE08> = 17;
<AE09> = 18;
<AE10> = 19;
<AE11> = 20;
<AE12> = 21;
<BKSP> = 22;
<TAB> = 23;
<AD01> = 24;
<AD02> = 25;
<AD03> = 26;
<AD04> = 27;
<AD05> = 28;
<AD06> = 29;
<AD07> = 30;
<AD08> = 31;
<AD09> = 32;
<AD10> = 33;
<AD11> = 34;
<AD12> = 35;
<RTRN> = 36;
<LCTL> = 37;
<AC01> = 38;
<AC02> = 39;
<AC03> = 40;
<AC04> = 41;
<AC05> = 42;
<AC06> = 43;
<AC07> = 44;
<AC08> = 45;
<AC09> = 46;
<AC10> = 47;
<AC11> = 48;
<TLDE> = 49;
<LFSH> = 50;
<BKSL> = 51;
<AB01> = 52;
<AB02> = 53;
<AB03> = 54;
<AB04> = 55;
<AB05> = 56;
<AB06> = 57;
<AB07> = 58;
<AB08> = 59;
<AB09> = 60;
<AB10> = 61;
<RTSH> = 62;
<KPMU> = 63;
<LALT> = 64;
<SPCE> = 65;
<CAPS> = 66;
<FK01> = 67;
<FK02> = 68;
<FK03> = 69;
<FK04> = 70;
<FK05> = 71;
<FK06> = 72;
<FK07> = 73;
<FK08> = 74;
<FK09> = 75;
<FK10> = 76;
<NMLK> = 77;
<SCLK> = 78;
<KP7> = 79;
<KP8> = 80;
<KP9> = 81;
<KPSU> = 82;
<KP4> = 83;
<KP5> = 84;
<KP6> = 85;
<KPAD> = 86;
<KP1> = 87;
<KP2> = 88;
<KP3> = 89;
<KP0> = 90;
<KPDL> = 91;
<SYRQ> = 92;
<II5D> = 93;
<LSGT> = 94;
<FK11> = 95;
<FK12> = 96;
<HOME> = 97;
<UP> = 98;
<PGUP> = 99;
<LEFT> = 100;
<II65> = 101;
<RGHT> = 102;
<END> = 103;
<DOWN> = 104;
<PGDN> = 105;
<INS> = 106;
<DELE> = 107;
<KPEN> = 108;
<RCTL> = 109;
<PAUS> = 110;
<PRSC> = 111;
<KPDV> = 112;
<RALT> = 113;
<BRK> = 114;
<LWIN> = 115;
<RWIN> = 116;
<MENU> = 117;
<FK13> = 118;
<FK14> = 119;
<FK15> = 120;
<FK16> = 121;
<FK17> = 122;
<KPDC> = 123;
<LVL3> = 124;
<ALT> = 125;
<KPEQ> = 126;
<SUPR> = 127;
<HYPR> = 128;
<XFER> = 129;
<I02> = 130;
<NFER> = 131;
<I04> = 132;
<AE13> = 133;
<I06> = 134;
<I07> = 135;
<I08> = 136;
<I09> = 137;
<I0A> = 138;
<I0B> = 139;
<I0C> = 140;
<I0D> = 141;
<I0E> = 142;
<I0F> = 143;
<I10> = 144;
<I11> = 145;
<I12> = 146;
<I13> = 147;
<I14> = 148;
<I15> = 149;
<I16> = 150;
<I17> = 151;
<I18> = 152;
<I19> = 153;
<I1A> = 154;
<I1B> = 155;
<META> = 156;
<K59> = 157;
<I1E> = 158;
<I1F> = 159;
<I20> = 160;
<I21> = 161;
<I22> = 162;
<I23> = 163;
<I24> = 164;
<I25> = 165;
<I26> = 166;
<I27> = 167;
<I28> = 168;
<I29> = 169;
<K5A> = 170;
<I2B> = 171;
<I2C> = 172;
<I2D> = 173;
<I2E> = 174;
<I2F> = 175;
<I30> = 176;
<I31> = 177;
<I32> = 178;
<I33> = 179;
<I34> = 180;
<K5B> = 181;
<K5D> = 182;
<K5E> = 183;
<K5F> = 184;
<I39> = 185;
<I3A> = 186;
<I3B> = 187;
<I3C> = 188;
<K62> = 189;
<K63> = 190;
<K64> = 191;
<K65> = 192;
<K66> = 193;
<I42> = 194;
<I43> = 195;
<I44> = 196;
<I45> = 197;
<K67> = 198;
<K68> = 199;
<K69> = 200;
<K6A> = 201;
<I4A> = 202;
<K6B> = 203;
<K6C> = 204;
<K6D> = 205;
<K6E> = 206;
<K6F> = 207;
<HKTG> = 208;
<HNGL> = 209;
<HJCV> = 210;
<AB11> = 211;
<I54> = 212;
<I55> = 213;
<I56> = 214;
<I57> = 215;
<I58> = 216;
<I59> = 217;
<I5A> = 218;
<K74> = 219;
<K75> = 220;
<K76> = 221;
<I5E> = 222;
<I5F> = 223;
<I60> = 224;
<I61> = 225;
<I62> = 226;
<I63> = 227;
<I64> = 228;
<I65> = 229;
<I66> = 230;
<I67> = 231;
<I68> = 232;
<I69> = 233;
<I6A> = 234;
<I6B> = 235;
<I6C> = 236;
<I6D> = 237;
<I6E> = 238;
<I6F> = 239;
<I70> = 240;
<I71> = 241;
<I72> = 242;
<I73> = 243;
<I74> = 244;
<I75> = 245;
<I76> = 246;
<I77> = 247;
<I78> = 248;
<I79> = 249;
<I7A> = 250;
<I7B> = 251;
<I7C> = 252;
<I7D> = 253;
<I7E> = 254;
<I7F> = 255;
indicator 1 = "Caps Lock";
indicator 2 = "Num Lock";
indicator 3 = "Scroll Lock";
virtual indicator 4 = "Shift Lock";
virtual indicator 5 = "Group 2";
virtual indicator 6 = "Mouse Keys";
alias <AE00> = <TLDE>;
alias <HZTG> = <TLDE>;
alias <I05> = <AE13>;
alias <IR7C> = <I7C>;
alias <IR7D> = <I7D>;
alias <K5C> = <KPEQ>;
alias <K70> = <HKTG>;
alias <K71> = <HNGL>;
alias <K72> = <HJCV>;
alias <K73> = <AB11>;
alias <LMTA> = <LWIN>;
alias <RMTA> = <RWIN>;
alias <COMP> = <MENU>;
alias <POWR> = <I0C>;
alias <MUTE> = <I0D>;
alias <VOL-> = <I0E>;
alias <VOL+> = <I0F>;
alias <HELP> = <I10>;
alias <STOP> = <I11>;
alias <AGAI> = <I12>;
alias <PROP> = <I13>;
alias <UNDO> = <I14>;
alias <FRNT> = <I15>;
alias <COPY> = <I16>;
alias <OPEN> = <I17>;
alias <PAST> = <I18>;
alias <FIND> = <I19>;
alias <CUT> = <I1A>;
alias <OUTP> = <I56>;
alias <KITG> = <I57>;
alias <KIDN> = <I58>;
alias <KIUP> = <I59>;
alias <MDSW> = <LVL5>;
alias <ALGR> = <RALT>;
alias <KPPT> = <I06>;
alias <AC12> = <BKSL>;
alias <LatQ> = <AD01>;
alias <LatW> = <AD02>;
alias <LatE> = <AD03>;
alias <LatR> = <AD04>;
alias <LatT> = <AD05>;
alias <LatY> = <AD06>;
alias <LatU> = <AD07>;
alias <LatI> = <AD08>;
alias <LatO> = <AD09>;
alias <LatP> = <AD10>;
alias <LatA> = <AC01>;
alias <LatS> = <AC02>;
alias <LatD> = <AC03>;
alias <LatF> = <AC04>;
alias <LatG> = <AC05>;
alias <LatH> = <AC06>;
alias <LatJ> = <AC07>;
alias <LatK> = <AC08>;
alias <LatL> = <AC09>;
alias <LatZ> = <AB01>;
alias <LatX> = <AB02>;
alias <LatC> = <AB03>;
alias <LatV> = <AB04>;
alias <LatB> = <AB05>;
alias <LatN> = <AB06>;
alias <LatM> = <AB07>;
};
@abelew could you create a (Github?) gist with the complete keymap? Do you know the exact keymap settings (rules, model, layout, variant, options)?
I believe you will find the entire keymap here:
https://gist.github.com/abelew/b39f6ec40b1e91a64d84a8c1a4dd9f57
I am not completely certain that I acquired the rules/model/layout/variant/options correctly; I pulled up the keyboard preferences application in mate. If this is correct, the keyboard model is a kinesis freestyle 2; the keyboard layout is currently English; variant is just US; and the only non-default option appears to be the use of the LED to indicate compose.
The terminal emulator configuration might be relevant in this context: I explicitly map shift+enter to send \x1b[13;2u and control+enter to send \x1b[13;5u . The caveat: I have the same configuration in multiple other terminal emulators (konsole and ghosttty) and have not triggered a segfault.
Thanks! It seems that this keymap compiles just fine with libxkbcommon 1.12.3.
I think I fixed the issue in #945 (will publish relevant 1.12 and 1.13 minor releases), but I fail to reproduce the issue with my xkeyboard-config setup. What version do you have (package can also be named xkb-data).
It seems the keymap comes from a non-evdev system (keycodes are xfree86), which indicates rules are either base or xorg.
I am really puzzled how to reproduce the issue with your keymap. Maybe it is about the different arch, resulting in different size of the structs. I will investigate further.
I apologize I am ignorant in this context and unable to provide the proper information without prompting. My xkb-data package is 2.42-1.
If it would help, I am happy to recompile libxkbcommon at whatever commit you prefer to see what happens. I have a stashed version which works for me, so I can try anything that would be of use to you.
I now have 4 trees:
- xkbcommon/libxkbcommon:HEAD: continued segfault at src/xkbcomp/keymap.c, realloc() line 416.
- wismill/libxkbcommon:HEAD: segfault at src/xkbcomp/keymap.c, realloc() line 416 (presumably this is the same as upstream, I did not check)
- my atb/libxkbcommon:BAD (containing the stupid #if 0 around the realloc): still working
- wismill/libxkbcommon:fix-aliases-v1.12: one time segfaulting at src/xkbcomp/keymap.c UpdateActionMods (oddly also at line 416); cleaned the tree, recompiled, then working fine!?
Given the odd behavior I was worried that I left some cruft while testing the first time and repeated each test, but first cleared out /usr/local/lib/libxk* between each iteration. I also added a printf i immediately after the outer for loop (e.g. for (xkb_layout_index_t i = 0; i < key->num_groups; i++)) before the inner loop in your tree to make sure that the section in question was hit. Thus far no problems.
- wismill/libxkbcommon:fix-aliases-v1.12: one time segfaulting at src/xkbcomp/keymap.c UpdateActionMods (oddly also at line 416); cleaned the tree, recompiled, then working fine!?
I force-pushed in #945 a few times after detecting an issue and to improve the code. Might be it?
I am still not satisfied that I cannot reproduce the issue with your own keymap.
Can you confirm that the remote where kitty runs:
- uses the Mate DE
- runs a X11 session (not Wayland)
- uses xkb-data-2.42-1 and libxkbcommon-1.12.3 packages
Could you try the following:
- Report the result of
setxkbmap -query - Launch Kitty with the following env variables:
XKB_LOG_LEVEL=debug XKB_LOG_VERBOSITY=11 - Report the relevant XKB log entries
Confirmation: yes, yes (with a caveat), yes: I run a mate X11 session via xrdp to my lab. This detail it turns out is relevant, I tested all of the above trees on a local host not via rdp and observed no segfault. I should have thought of that to begin with.
I am unaware of any changed xkb settings; on other hosts I have a bunch of xresources/xkb entries so that I can use a Sun keyboard, but I checked and they are not here. With that in mind, the result of setxkbmap -query is:
rules: base
model: pc104
layout: us
I am creating another gist from the result of:
XKB_LOG_LEVEL=debug XKB_LOG_VERBOSITY=11 kitty >/tmp/xkb_debug_kitty.txt 2>&1
using the currently installed libxkbcommon_wismill_fix tree. I am guessing it might prove useful to repeat using a subset of the others and/or repeat outside of a xrdp session?
https://gist.github.com/abelew/b7a67d93bde35a2ad2247b24aae1cb83
No worries, thank you for your time, I hope I did not add any frustration to your day.