Irssi core bugs

Notice: Undefined index: tasklist_type in /var/www/ : eval()'d code on line 85 Notice: Undefined index: tasklist_type in /var/www/ : eval()'d code on line 90
  • Status New
  • Percent Complete
  • Task Type Bug Report
  • Category core
  • Assigned To No-one
  • Operating System Linux
  • Severity Low
  • Priority Normal
  • Reported Version irssi 0.8.15
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 0
  • Private No
Attached to Project: Irssi core bugs
Opened by Matthijs Kooijman (matthijs) - 2011-01-25
Last edited by Wouter Coekaerts (coekie) - 2011-01-27

FS#788 - Infinite loop / segfault on particular keybindings

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.

This task does not depend on any other tasks.

Wouter Coekaerts (coekie)
Thursday, 27 January 2011, 19:05 GMT
  • Field changed: Status (Unconfirmed → New)
Thanks for the clear explanation. Ignoring any recursive expansion would make the most sense to me.