[BUG] LLDB's bundled ncurses6 can't read terminal database on Linux/Darwin

macOS

When I start LLDB on macOS (11.5.1 "Big Sur"), it fails with a terminal error:

$ export DYLD_LIBRARY_PATH=$HOME/android-ndk-r23/toolchains/llvm/prebuilt/darwin-x86_64/python3/lib 
$ ./android-ndk-r23/toolchains/llvm/prebuilt/darwin-x86_64/bin/lldb
terminals database is inaccessible
$

I don't think I'm supposed to need DYLD_LIBRARY_PATH, but if I remove it, I get a different failure (#1566).

I don't know if this affects Android Studio, but hopefully not? The current version of Android Studio I have installed on macOS doesn't have a bundled ncurses. IIRC we recently started bundling ncurses with Studio's LLDB. Instead, the binaries I have use the system ncurses:

/Applications/Android Studio.app/Contents/bin/lldb/lib64$ otool -L liblldb.11.0.4git.dylib 
liblldb.11.0.4git.dylib:
	@rpath/liblldb.11.0.4git.dylib (compatibility version 0.0.0, current version 11.0.4)
	@rpath/libpython3.8.dylib (compatibility version 3.8.0, current version 3.8.0)
	/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
	/usr/lib/libform.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
	/usr/lib/libpanel.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
	@rpath/libxml2.2.9.10.dylib (compatibility version 0.0.0, current version 2.9.10)
	@rpath/libedit.0.dylib (compatibility version 1.0.0, current version 1.61.0)
        ...

(Studio's lib64 directory has a libedit.0.dylib and a libpython3.8.dylib in it.)

Linux

When I start LLDB on Linux, I see this prompt.

$ cd prebuilts/clang/host/linux-x86/clang-r428724
$ LD_LIBRARY_PATH=$PWD/python3/lib ./bin/lldb
Cannot read termcap database;
using dumb terminal settings.
(lldb)

(I tested with CentOS 8 and Ubuntu 20.04, in addition to gLinux.)

termcap is obsolete in favor of terminfo, but I don't think that's the issue. I think we're using the AOSP libedit (~~which seems to be a tarball from Apple?~~ corrected below), which depends on the ncurses we're shipping.

I assume the error is coming from here:
https://android.googlesource.com/platform/external/libedit/+/refs/heads/llvm-r416183/src/terminal.c#869

If I delete the DSOs, the error goes away:

$ rm lib64/libncurses.so.6 lib64/libpanel.so.6 lib64/libform.so.6 
$ LD_LIBRARY_PATH=$PWD/python3/lib ./bin/lldb
(lldb)

Line editing largely works anyway. I noticed that long-line editing was broken. This line is suspicious:
https://android.googlesource.com/platform/external/libedit/+/refs/heads/llvm-r416183/src/terminal.c#875

Example:

Resize terminal to 120 columns.
Type Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vestibulum purus sed vestibulum euismod. Sed est lacus, iaculis a diam eget, accumsan blandit arcu. and press Enter.
Press Up, Down, Up, Down, etc.

The output looks like:

$ LD_LIBRARY_PATH=$PWD/python3/lib ./bin/lldb
Cannot read termcap database;
using dumb terminal settings.
(lldb) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vestibulum purus sed vestibulum euismod. Sed est 
lacus, iaculis a diam eget, accumsan blandit arcu.
error: 'Lorem' is not a valid command.
(lldb) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vestibulum purus sed vestibulum euismod. Sed est
(lldb)                                                                                                                 
(lldb) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vestibulum purus sed vestibulum euismod. Sed est 
(lldb)                                                                                                                 
(lldb) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vestibulum purus sed vestibulum euismod. Sed est 
(lldb)                                                                                                                 
(lldb) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vestibulum purus sed vestibulum euismod. Sed est 
(lldb)                                                                                                                 
(lldb) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vestibulum purus sed vestibulum euismod. Sed est 
(lldb)                                                                                                                 
(lldb) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vestibulum purus sed vestibulum euismod. Sed est 
(lldb)                                                                                                                 
(lldb) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vestibulum purus sed vestibulum euismod. Sed est 
lacus, iaculis a diam eget, accumsan blandit arcu.

This example works correctly if the DSOs are deleted.

The LLDB from the upstream clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-20.04 package uses the libncurses6 DSOs (libncurses.so.6, libform.so.6, libpanel.so.6, libtinfo.so.6), but there's no DT_NEEDED for *edit* or *readline*. It has no line editing. (I've been using it to test e.g. https://llvm.org/PR50935, so I use rlwrap lldb to get line editing.)

IIRC we recently started bundling ncurses with Studio's LLDB.

I'm thinking of http://b/172971586.

I think we're using the AOSP libedit (which seems to be a tarball from Apple?), which depends on the ncurses we're shipping.

shouldn't be... METADATA says

  url {
    type: HOMEPAGE
    value: "https://www.thrysoee.dk/editline/"
  }
  url {
    type: ARCHIVE
    value: "https://www.thrysoee.dk/editline/libedit-20191025-3.1.tar.gz"
  }

that project in turn seems to be tracking the BSD upstream (http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit).

(so we are out of date. this is an interesting case, where even if hhb was still around to run the script, we wouldn't catch this project because it's not in the AOSP manifest. [i don't think we can handle arbitrary download URLs anyway, only github, so there are many problems here. TL;DR: if you do update libedit, please keep METADATA up to date :-) ])

This line is suspicious:
https://android.googlesource.com/platform/external/libedit/+/refs/heads/llvm-r416183/src/terminal.c#875

it looks like they already have the code they need in terminal_get_size() in the same file, they're just not calling it. i know it's not the long-term fix, but might be worth sending a patch for that? (even if it doesn't cover SIGWINCH, it's still going to be right in more cases than the code currently is :-) ) hmm... looks like they already do that at the end of the function you linked to with the = 80...

				/* get the correct window size */
	(void) terminal_get_size(el, &lins, &cols);

I think we're using the AOSP libedit (which seems to be a tarball from Apple?), which depends on the ncurses we're shipping.

shouldn't be... METADATA says

Oh, it seems I searched for "libedit 20191025", found this macports link, then confused macports with Apple's own tarballs. I didn't realize there was a URL in the METADATA file. That's helpful.

yeah, not all METADATA files have that information, but it's the goal! any time you do the detective work to find where some code came from, i'm happy to +2 a CL that adds the corresponding METADATA. especially if it's a github URL and SHA, because then hhb's update script can do its magic...

(fyi, looks like libedit is no longer in the lldb-master-dev manifest. there is a newer version at https://www.thrysoee.dk/editline/ but since afaik no-one's using the version we have, i haven't updated it.)

@pirama-arumuga-nainar

(fyi, looks like libedit is no longer in the lldb-master-dev manifest. there is a newer version at https://www.thrysoee.dk/editline/ but since afaik no-one's using the version we have, i haven't updated it.)

@pirama-arumuga-nainar says this isn't true, so someone probably should update that...

FWIW, with llvm-toolchain built locally on an M1, lldb.sh works:

$ out/install/darwin-x86/clang-dev/bin/lldb.sh
(lldb) 
error: empty command
(lldb)

IIUC, we want to be bundling our own ncurses because the build servers may not have them and also to avoid difference across different OS versions.

We should update external/libncurses and check if a prebuilt from a non-M1 mac works fine on an M1 Mac.

@rprichard

lldb is still broken after the ncurses upgrade. (In build https://ci.android.com/builds/branches/aosp-llvm-toolchain/grid?head=9269573&tail=9269573).

This issue, and the dependent #1749, are part of r25c. @rprichard Do you have any other pointers for this?

lldb is still broken after the ncurses upgrade.

define "broken"? i think there are several issues on this bug from "lldb won't start because it can't find a needed library" to "line editing doesn't work right". which end of that spectrum are you on? (and if the former, what does your otool output look like?)

Is there any known workaround for this issue? I'm seeing the same behavior described above:

$ ./lldb.sh
terminals database is inaccessible
$ TERMINFO=/usr/share/terminfo ./lldb.sh
'xterm-256color': unknown terminal type.

macOS 13.3, NDK version 25.2.9519653 installed through the SDK manager from Android Studio.

I was experiencing this issue while debugging root daemons and system processes (e.g. surfaceflinger) on a device/emulator on macOS 13.x

I used gdbclient.py's --setup-forwarding argument as a workaround, so that (I presume) the python script doesn't have to take over the terminal's input and output, but it requires entering the commands yourself in lldb in order to attach to the gdb/lldbserver on the device/emulator

(the script provides the commands for you if you use --setup-forwarding)

The 78 vs x difference is because Mac has a case-insensitive file system where the subdirs of /usr/share/terminfo are ascii values ('78') instead of letters ('x'). The ncurses configure script detects this based on the filesystem it's running on. Unfortunately, the android builds run on a separate volume with a case-sensitive file system, breaking this detection. I was able to fix/override this detection by setting the --disable-mixed-case configure flag.

The other issue with TERMINFO dir can be fixed by setting --with-default-terminfo-dir.

Fix is in https://android-review.googlesource.com/c/toolchain/llvm_android/+/2583755. I'll verify a post-submit build and then plan to fix this at the very least in r26 if not in an r25 point release.

Mac has a case-insensitive file system

(oh, is that why they do that? i'd always assumed it was just a %d versus %c bug in their implementation that they couldn't change for backwards compatibility!)

Mac has a case-insensitive file system
(oh, is that why they do that?

Yea, the actual rationale was sprinkled across a few different files. The help-text for the mixed-case option did not imply it relates to how TERMINFO is found 👎 .

Is there any known workaround for this issue?

I did stumble upon one yesterday.

$ mkdir -p ~/.terminfo
$ cd ~/.terminfo
$ ln -s /usr/share/terminfo/78 x

This should work for terminal names that start with an x. For other terminals, replace the last command with the starting letter and the corresponding ascii value (in hex).

(yeah, i've been using the symlink workaround for about 20 years now :-) )

Overwrite clang-r487747c/lib/libncurses.6.dylib

Overwrite clang-r487747c/lib/libncurses.so.6

@pirama-arumuga-nainar

Fixed in: https://android-review.git.corp.google.com/c/toolchain/llvm_android/+/2587443 Thanks @pirama-arumuga-nainar for fixing it.

I think this is the right CL - https://android-review.googlesource.com/c/toolchain/llvm_android/+/2583755

Fix terminfo detection in libncurses

Navigation Menu

Repository navigation

[BUG] LLDB's bundled ncurses6 can't read terminal database on Linux/Darwin #1565

macOS

Linux

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG] LLDB's bundled ncurses6 can't read terminal database on Linux/Darwin #1565

Description

macOS

Linux

Activity

rprichard commented on Aug 20, 2021

rprichard commented on Aug 20, 2021

enh-google commented on Aug 20, 2021

rprichard commented on Aug 20, 2021

enh-google commented on Aug 20, 2021

enh-google commented on Aug 16, 2022

enh-google commented on Aug 26, 2022

pirama-arumuga-nainar commented on Nov 3, 2022

pirama-arumuga-nainar commented on Nov 9, 2022

enh-google commented on Nov 9, 2022

6 remaining items

gsingh93 commented on Apr 8, 2023

YungRaj commented on Apr 18, 2023

pirama-arumuga-nainar commented on May 10, 2023

enh-google commented on May 10, 2023

pirama-arumuga-nainar commented on May 10, 2023

enh-google commented on May 10, 2023

appujee commented on May 15, 2023

stephenhines commented on May 15, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions