Infinite loop / segfault on particular keybindings

[irssibot]

• • • Issue #788 opened by @matthijs

The keybindings engine can get stuck in an infinite loop (eventually segfaulting after running out of memory) when a particular kind of recursive keybinding is entered. As an example, the following command shows this problem:

 /bind meta-x key meta

When saving this keybinding, the key_states_rescan function calls key_states_scan_key, which calls expand_key. When expand_key encounters the "meta" in "meta-x" in the example, it will look up all possible sequences that can generate the "meta" key (in this case, "meta-x" as well as "^]" from the default keybindings). Each of these will be expanded again, which leads to the infinite loop.

Note that this analysis is only based on code review, I haven't actually verified this using a debugger.

At first glance, a recursive binding like this does not make any sense, but my original use case was to use the F1 key as an alternative to the "ESC" key for switching windows.

A quick google showed that F1 is often meta2-P and ESC is mapped as meta, I tried mapping meta2-P to key meta, which crashed (since meta2 is really meta-O). I've since found out that binding ^]OP to key meta works just fine (since ^] is normally bound to meta and F1 is really just ^]OP). This is probably even the better solution, since my original attempt would also allow pressing F1-F1-F1-F1-2 to switch to window 2, which isn't really needed.

It's probably fine to have irssi give a warning in such a case and ignore the keybinding. Or perhaps it could just ignore any recursive expansions and only use the non-recursive expansion (or perhaps limit at, say, 10 keys deep or something).

Anyway, this isn't a big issue, but it would be nice if irssi wouldn't crash in this particular case.

[irssibot]

• • • Comment 1290 by @coekie

Thanks for the clear explanation. Ignoring any recursive expansion would make the most sense to me.