(lldb) prompt sometimes not printed on startup when statusline is enabled

[DavidSpickett]

Sometimes when I start lldb with no arguments I get:

$ ./bin/lldb
<<< cursor points to the beginning of this line
< the status bar>

When it works correctly I get:

$ ./bin/lldb
(lldb) <<< cursor is one space beyond the prompt
<the status bar>

I tried various things like removing the history file, or quitting lldb with ctrl-d vs. the quit command. None of that made the behaviour consistent. So it could be some startup event finishing with different timings.

Adding a program file to the command line fixes this:

$ ./bin/lldb /tmp/test.o
(lldb) target create "/tmp/test.o"
Current executable set to '/tmp/test.o' (aarch64).
(lldb) << cursor one beyond the prompt
test.o << the status bar

Likely because this garauntees some update event to make the prompt print.

Could be platform specific, so here are host details:

$ arch
aarch64
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.5 LTS
Release:        22.04
Codename:       jammy
$ ldd ./bin/lldb
        linux-vdso.so.1 (0x0000ffff9ca7d000)
        liblldb.so.21.0git => /home/david.spickett/build-llvm-aarch64/./bin/../lib/liblldb.so.21.0git (0x0000ffff91450000)
        libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffff913b0000)
        libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000ffff91380000)
        libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000ffff91150000)
        libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000ffff91120000)
        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff90f70000)
        libpython3.10.so.1.0 => /lib/aarch64-linux-gnu/libpython3.10.so.1.0 (0x0000ffff90990000)
        libpanel.so.6 => /lib/aarch64-linux-gnu/libpanel.so.6 (0x0000ffff90970000)
        libncurses.so.6 => /lib/aarch64-linux-gnu/libncurses.so.6 (0x0000ffff90930000)
        libtinfo.so.6 => /lib/aarch64-linux-gnu/libtinfo.so.6 (0x0000ffff908e0000)
        libform.so.6 => /lib/aarch64-linux-gnu/libform.so.6 (0x0000ffff908b0000)
        libxml2.so.2 => /lib/aarch64-linux-gnu/libxml2.so.2 (0x0000ffff906c0000)
        libedit.so.2 => /lib/aarch64-linux-gnu/libedit.so.2 (0x0000ffff90670000)
        liblzma.so.5 => /lib/aarch64-linux-gnu/liblzma.so.5 (0x0000ffff90630000)
        /lib/ld-linux-aarch64.so.1 (0x0000ffff9ca44000)
        libexpat.so.1 => /lib/aarch64-linux-gnu/libexpat.so.1 (0x0000ffff905f0000)
        libicuuc.so.70 => /lib/aarch64-linux-gnu/libicuuc.so.70 (0x0000ffff903e0000)
        libbsd.so.0 => /lib/aarch64-linux-gnu/libbsd.so.0 (0x0000ffff903b0000)
        libicudata.so.70 => /lib/aarch64-linux-gnu/libicudata.so.70 (0x0000ffff8e780000)
        libmd.so.0 => /lib/aarch64-linux-gnu/libmd.so.0 (0x0000ffff8e760000)
$ apt list --installed | grep curses

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libncurses-dev/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 arm64 [installed,automatic]
libncurses5-dev/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 arm64 [installed]
libncurses5/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 arm64 [installed]
libncurses6/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 arm64 [installed]
libncursesw6/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 arm64 [installed]
ncurses-base/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 all [installed]
ncurses-bin/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 arm64 [installed]

Built lldb from 9b2fd1a.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: David Spickett (DavidSpickett)

Sometimes when I start lldb with no arguments I get: ``` $ ./bin/lldb <<< cursor points to the beginning of this line < the status bar> ``` When it works correctly I get: ``` $ ./bin/lldb (lldb) <<< cursor is one space beyond the prompt <the status bar> ``` I tried various things like removing the history file, or quitting lldb with ctrl-d vs. the quit command. None of that made the behaviour consistent. So it could be some startup event finishing with different timings.

Adding a program file to the command line fixes this:

$ ./bin/lldb /tmp/test.o
(lldb) target create "/tmp/test.o"
Current executable set to '/tmp/test.o' (aarch64).
(lldb) << cursor one beyond the prompt
test.o << the status bar

Likely because this garauntees some update event to make the prompt print.

Could be platform specific, so here are host details:

$ arch
aarch64
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.5 LTS
Release:        22.04
Codename:       jammy
$ ldd ./bin/lldb
        linux-vdso.so.1 (0x0000ffff9ca7d000)
        liblldb.so.21.0git => /home/david.spickett/build-llvm-aarch64/./bin/../lib/liblldb.so.21.0git (0x0000ffff91450000)
        libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffff913b0000)
        libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000ffff91380000)
        libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000ffff91150000)
        libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000ffff91120000)
        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff90f70000)
        libpython3.10.so.1.0 => /lib/aarch64-linux-gnu/libpython3.10.so.1.0 (0x0000ffff90990000)
        libpanel.so.6 => /lib/aarch64-linux-gnu/libpanel.so.6 (0x0000ffff90970000)
        libncurses.so.6 => /lib/aarch64-linux-gnu/libncurses.so.6 (0x0000ffff90930000)
        libtinfo.so.6 => /lib/aarch64-linux-gnu/libtinfo.so.6 (0x0000ffff908e0000)
        libform.so.6 => /lib/aarch64-linux-gnu/libform.so.6 (0x0000ffff908b0000)
        libxml2.so.2 => /lib/aarch64-linux-gnu/libxml2.so.2 (0x0000ffff906c0000)
        libedit.so.2 => /lib/aarch64-linux-gnu/libedit.so.2 (0x0000ffff90670000)
        liblzma.so.5 => /lib/aarch64-linux-gnu/liblzma.so.5 (0x0000ffff90630000)
        /lib/ld-linux-aarch64.so.1 (0x0000ffff9ca44000)
        libexpat.so.1 => /lib/aarch64-linux-gnu/libexpat.so.1 (0x0000ffff905f0000)
        libicuuc.so.70 => /lib/aarch64-linux-gnu/libicuuc.so.70 (0x0000ffff903e0000)
        libbsd.so.0 => /lib/aarch64-linux-gnu/libbsd.so.0 (0x0000ffff903b0000)
        libicudata.so.70 => /lib/aarch64-linux-gnu/libicudata.so.70 (0x0000ffff8e780000)
        libmd.so.0 => /lib/aarch64-linux-gnu/libmd.so.0 (0x0000ffff8e760000)
$ apt list --installed | grep curses

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libncurses-dev/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 arm64 [installed,automatic]
libncurses5-dev/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 arm64 [installed]
libncurses5/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 arm64 [installed]
libncurses6/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 arm64 [installed]
libncursesw6/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 arm64 [installed]
ncurses-base/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 all [installed]
ncurses-bin/jammy-updates,jammy-security,now 6.3-2ubuntu0.1 arm64 [installed]

Built lldb from 9b2fd1a.

[DavidSpickett]

@JDevlieghere please try to reproduce this and if you can't, give me your best guess as to what it could be and I'll try to find it myself.

[JDevlieghere]

I can't quite reproduce the prompt being out of place when launching lldb, but if I resize the terminal, the cursor ends up before the prompt. My unfounded suspicion is that this has something to with how Editline redraws the colored prompt over the old one, and maybe we get that wrong. I've assigned it to myself to investigate.

[DavidSpickett]

but if I resize the terminal, the cursor ends up before the prompt.

I didn't mention I was using tmux, so maybe my terminal is in some odd state. In a normal terminal session I can reproduce what you saw:

$ ./bin/lldb
(lldb) 
^--------cusror is here, over the opening bracket

After resizing it goes back to not printing (lldb) again, but sometimes it will, odd.

I have use-color set to the default true.

[JDevlieghere]

I think I know what's causing this. When we're enabling the statusline, we do the following:

   111      // Move everything on the screen up.
   112      locked_stream.Printf(ANSI_UP_ROWS, 1);
   113      locked_stream << '\n';

If we start out like this:

❯ ./bin/lldb
(lldb)█

The first escape code moves the cursor up.

❯ ./bi█/lldb
(lldb)

And then the newline moves everything up, moving the cursor to the start of the line:

❯ ./bin/lldb
█lldb)

[JDevlieghere]

The issue seems deceivingly simple, but I'm having a hard time coming up with a solution...

When we enable the statusline, we're essentially giving up one row at the bottom of the terminal. That requires special handling if we're at the bottom of the terminal (which is something we don't know). I wrote the code slightly differently to avoid having to check twice if we're enabling the statusline, but here's an easier to understand version that's equivalent:

// Move everything on the screen up so nothing gets covered by the statusline.
locked_stream << '\n';

// Reduce the scroll window.
locked_stream << ANSI_SAVE_CURSOR;
locked_stream.Printf(ANSI_SET_SCROLL_ROWS, scroll_height);
locked_stream << ANSI_RESTORE_CURSOR;

// The cursor is now in the non-scrollable part of the terminal. Move it up one row to get out of there.
locked_stream.Printf(ANSI_UP_ROWS, 1);

The problem is that the newline moves the cursor to first column. I tried the SU escape code (CSI 1 S) but that has the same effect and is probably just implemented in terms of emitting newlines.

• If there was an escape code that saves and restores just the column (and not both the row and column) I could invoke that before and after emitting the newline, but I'm not aware of such a thing.
• There are escape codes to get the current cursor position, but it requires another level of messing with the terminal to echo and read them and I would really, really like to avoid that.

[DavidSpickett]

That requires special handling if we're at the bottom of the terminal (which is something we don't know).

I also see a problem with the last line on Windows, but the details aren't the same - #134846 (comment)

Does not happen on Linux though, so probably not the same cause as the problem discussed here.

[labath]

A couple of (possibly bad) ideas:

• IIUC, the problem is that we can't save only the column of the cursor. Couldn't we work around that by first moving the cursor to the expected final position (same column, one row above the current position?) and then saving the cursor position (both coordinates)?
• could we ask editline to redraw the current line after we mess with the terminal?
• could we make sure status line is enabled before editline gets a chance to print the prompt?

• There are escape codes to get the current cursor position, but it requires another level of messing with the terminal to echo and read them and I would really, really like to avoid that.

Yeah, that sounds messy.