FS#49974 - [lldb] libedit 20160618_3.1 breaks input

Attached to Project: Arch Linux
Opened by Moritz Kiefer (cocreature) - Wednesday, 06 July 2016, 18:57 GMT
Last edited by Evangelos Foutras (foutrelis) - Friday, 26 May 2017, 00:06 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Evangelos Foutras (foutrelis)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 13
Private No

Details

Description:
After upgrading to [[libedit 20160618_3.1]] lldb no longer recognizes characters correctly. Instead they are shown (and handled as) weird unicode escape sequences, e.g. "\U+96272\U+96275\U+9626E" instead of "run". The exact numbers also seem to change between restarts but the last two numbers always represent the correct ascii hex code.

The libedit changelog says
```
deprecate option --enable-widec.
Upstream now always build with unicode (wide-char/UTF-8) support.
```
which seems like it might be related.

Steps to reproduce:
Install lldb 3.8 and libedit 20160618_3.1, launch lldb and try to type anything.
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Friday, 26 May 2017, 00:06 GMT
Reason for closing:  Fixed
Additional comments about closing:  lldb 4.0.0-3
Comment by Doug Newgard (Scimmia) - Thursday, 07 July 2016, 01:21 GMT
Are you using a non-UTF8 locale?
Comment by Moritz Kiefer (cocreature) - Thursday, 07 July 2016, 05:51 GMT
No I’m using "en_US.utf8".
Comment by Moises Silva (moy) - Saturday, 16 July 2016, 18:33 GMT
I can confirm this. Same behaviour here. I am using en_CA.utf8
Comment by Moises Silva (moy) - Saturday, 16 July 2016, 18:51 GMT
I installed libedit from sources (http://thrysoee.dk/editline/libedit-20160618-3.1.tar.gz) using ./configure --prefix=/opt/libedit && make install and then exported LD_LIBRARY_PATH=/opt/libedit/lib, but the bug persisted. I then installed the previous version from sources using the same method and my applications started working again, so this seems to point to a bug upstream.
Comment by Moises Silva (moy) - Saturday, 16 July 2016, 18:51 GMT
Sources that work for me: http://cjj.kr.distfiles.macports.org/libedit/libedit-20150325-3.1.tar.gz
Comment by Moises Silva (moy) - Saturday, 16 July 2016, 23:46 GMT
Also, fwiw, I am not using lldb. Same behavior is present in the Asterisk (www.asterisk.org) console.
Comment by Gaetan Bisson (vesath) - Sunday, 17 July 2016, 06:56 GMT
Please report this upstream at: http://thrysoee.dk/contact.php
Comment by Moritz Kiefer (cocreature) - Sunday, 17 July 2016, 07:07 GMT
This seems to be an LLVM bug, rather than a libedit bug. If you look in `lldb/Host/Editline.h there is already a flag called LLDB_EDITLINE_USE_WCHAR which is atm only enabled when you are on macos. If you set that to true manually input is working (I’m still getting a crash on exit, but that might be a separate problem). So it is an upstream bug, but an upstream bug in LLDB, I’ll see when I get around to reporting it.
Comment by Yury (MerSharik) - Monday, 18 July 2016, 07:58 GMT
I observe the same behaviour in lldb. In my system LANG=en_SG.UTF-8. I tried the same lldb version 3.8.0 in Ubuntu 16.04 LTS. And it works fine.
Comment by Pablo H.Cerdan (phcerdan) - Wednesday, 27 July 2016, 14:02 GMT
Same here, is this already reported upstream?
Comment by Moritz Kiefer (cocreature) - Thursday, 28 July 2016, 19:24 GMT
Not yet, I’m quite busy atm and haven’t gotten around to it so far.
Comment by Pablo H.Cerdan (phcerdan) - Monday, 08 August 2016, 02:40 GMT
I just contacted libedit developers, Jess Thrysoee (jess_AT_thrysoee.dk) provided feedback:
Quote:
{
The NetBSD upstream for my package [..libedit..] now only build with unicode (wide-char/UTF-8) support.
So it looks like LLDB_EDITLINE_USE_WCHAR=1 should be used on Arch Linux:
https://github.com/llvm-mirror/lldb/search?utf8=%E2%9C%93&q=LLDB_EDITLINE_USE_WCHAR
}

This just agrees with Moritz Kiefer, I didn't read your message on time.
Reported to lldb:
https://llvm.org/bugs/show_bug.cgi?id=28898
Comment by Evangelos Foutras (foutrelis) - Wednesday, 26 October 2016, 15:24 GMT
Enabling LLDB_EDITLINE_USE_WCHAR results in a crash when exiting LLDB and also eats the first character typed in LLDB at the start of the session.

I've opted to disable libedit in LLDB for now until a better solution becomes known; it's worth noting that FreeBSD has reverted their libedit version bump, quoting LLDB breakage as the reason. [1]

[1] https://svnweb.freebsd.org/base?view=revision&revision=296435
Comment by Quaquaraqua (Quaquaraqua) - Friday, 06 January 2017, 18:17 GMT
  • Field changed: Percent Complete (100% → 0%)
The introduced fix, https://lists.archlinux.org/pipermail/arch-commits/2016-October/357137.html, sets the flag LLDB_DISABLE_LIBEDIT=1. While this resolves the first reported issue, it creates a new problem, having the arrow keys not working anymore. The usage of the console inside the debugger becomes a nightmare. For instance it is not possible to go backwards with the left key and correct a typed character.
Other users preferred just to avoid updating libedit, without being exposed to the bug ftb. However the patch makes useless the above workaround and introduces a new annoying behaviour.
Comment by Xinkai Chen (Xinkai) - Sunday, 30 April 2017, 17:29 GMT
Posting an update on this, in case anyone is interested.

After replacing
"#define LLDB_EDITLINE_USE_WCHAR 0" with
"""
#define LLDB_EDITLINE_USE_WCHAR 1
#include <codecvt>
""" in "src/llvm-4.0.0.src/tools/lldb/include/lldb/Host/Editline.h", I got lldb working, including normal typing(ASCII), arrow keys, ctrl+C/ctrl+D, and there's no crashing when exiting lldb. Maybe it's due to the recent llvm update, or the libedit update. Anyway, can someone confirm this?

It's not a complete fix though, as Chinese characters and other non-ASCII latin characters are still incorrectly displayed, like "\U+6D4B\U+8BD5".

Loading...