This bug seems to be causing some cases of TestCompletion to fail consistently when GCC is the test compiler... at least on the buildbot:

http://lab.llvm.org:8011/builders/lldb-x86_64-linux/builds/2360/steps/test/logs/stdio

To anyone that's really annoyed by this bug, you can work-around it by issuing a Ctrl-C to in the LLDB utility (when the inferior is stopped) to get the prompt to show up again...

Although I wasn't able to reproduce this issue with the same commands as Sid, I was able to reproduce it like so:

Current executable set to 'a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 32 at main.cpp:57, address = 0x00000000004007d0
(lldb) r
Process 5288 launched: '/home/mkopec1/dev/llvm/tools/lldb/test/functionalities/abbreviation/a.out' (x86_64)
Process 5288 stopped

• thread #​1: tid = 0x14a8, 0x00000000004007d0 a.outmain(argc=1, argv=0x00007fff16c44ec8) + 32 at main.cpp:57, stop reason = breakpoint 1.1 frame #​0: 0x00000000004007d0 a.outmain(argc=1, argv=0x00007fff16c44ec8) + 32 at main.cpp:57
  54
  55 int array[3];
  56
  -> 57 array[0] = foo (1238, 78392);
  58 array[1] = foo (379265, 23674);
  59 array[2] = foo (872934, 234);
  60
  t 1
• thread #​1: tid = 0x14a8, 0x00000000004007d0 a.outmain(argc=1, argv=0x00007fff16c44ec8) + 32 at main.cpp:57, stop reason = breakpoint 1.1 frame #​0: 0x00000000004007d0 a.outmain(argc=1, argv=0x00007fff16c44ec8) + 32 at main.cpp:57
  54
  55 int array[3];
  56
  -> 57 array[0] = foo (1238, 78392);
  58 array[1] = foo (379265, 23674);
  59 array[2] = foo (872934, 234);
  60

I traced this down to the NetBSD editline library (libedit). My system default has libedit 2.11 and upgrading to libedit 3.0 seems to resolve the problem of the missing lldb prompt. The lldb binary links against this library. Additionally, my mac system las libedit 3.0 by default and the problem doesn't reproduce there.

I am not able to repro this using Sid's or Matt's repro steps. I'm on Ubuntu x64 12.04.2, and lldb is loading libedit.so.2.11 (2.11-20080614). I'm testing under Unity with gnome-terminal.

Matt: You're just doing a "b main", "r", "t 1", yes? What distro and window manager are you using?

If needed, can we pull a later version of Linux libedit into the lldb source tree and build using that static library? Arch uses this upstream version I believe: http://www.thrysoee.dk/editline/ ( found from https://www.archlinux.org/packages/core/i686/libedit/ )

Thanks!

mikesart@mikesart-rad:~/data/src/blah/build$ ~/data/src/llvm/build/bin/lldb --debug -f ./blah
Current executable set to './blah' (x86_64).
(lldb) b main
Breakpoint 1: where = blah`main + 4 [inlined] printf at blah.cpp:42, address = 0x0000000000438444
(lldb) r
Process 9378 launched: './blah' (x86_64)
Process 9378 stopped

• thread #​1: tid = 0x24a2, 0x0000000000438444 blahmain [inlined] printf(__fmt=0x00000000004ac793) at stdio2.h:105, stop reason = breakpoint 1.1 frame #​0: 0x0000000000438444 blahmain [inlined] printf(__fmt=0x00000000004ac793) at stdio2.h:105
  102 __extern_always_inline int
  103 printf (__const char *__restrict __fmt, ...)
  104 {
  -> 105 return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
  106 }
  107 # elif !defined __cplusplus
  108 # define printf(...)
  (lldb) t 1
• thread #​1: tid = 0x24a2, 0x0000000000438444 blahmain [inlined] printf(__fmt=0x00000000004ac793) at stdio2.h:105, stop reason = breakpoint 1.1 frame #​0: 0x0000000000438444 blahmain [inlined] printf(__fmt=0x00000000004ac793) at stdio2.h:105
  102 __extern_always_inline int
  103 printf (__const char *__restrict __fmt, ...)
  104 {
  -> 105 return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
  106 }
  107 # elif !defined __cplusplus
  108 # define printf(...)
  (lldb) version
  lldb version 3.4 (http://llvm.org/svn/llvm-project/lldb/trunk revision 181741)
  (lldb)

I tried to repro this today using the same steps I wrote previously but was unable to. I'm running Ubuntu 12.10 64-bit, libedit 2.11-20080614-5, Unity and GNOME Terminal 3.6.0.

Coincidentally, there was a commit today, r181807, that may have fixed the issues that I was seeing in the past. I'm checking with the author to see if he is still seeing Linux prompt issues.

Unable to repro locally either, with the same versions as Matt.

I removed the @​expectedFail decorator on the tests affected by this bug. Will watch the buildbots to see if anything is still broken...and close this bug accordingly if nothing breaks.

Here's hoping this pesky issue has been fixed :)

This still happens to me all the time (ubuntu 13.04 x64), from head.

Indeed, this is still a problem with older libedit versions. TestStopHookMultipleThreads fails on the GCC buildbot because of this bug.

Our friend Sylvestre has updated the Ubuntu package of libedit, but it has not made it into 13.04 yet:

https://launchpad.net/ubuntu/+source/libedit

If all goes well, Ubuntu 13.10 should have the updated version and we will no longer run into this problem.

Fixed (hopefully for good) with r191392. The fix does not require an update libedit.

Hi, this is still happening for me on Fedora 19 with trunk (r192427) as of today.

I'm using: libedit-devel-3.0-10.20121213cvs.fc19.x86_64

I can reproduce by just setting a breakpoint in main and running, the backtrace is shown for the thread, and no prompt is re-printed.

Should this bug be re-opened?

yeah, I guess so....

I've just noticed that the prompt is printed after all ... but, this is being done before the process has stopped, eg.:

$ lldb -- $(pwd)/test.gnu
Current executable set to '.../test.gnu' (x86_64).
(lldb) run
Process 15521 launched: '.../test.gnu' (x86_64)
(lldb) n = 1
n = 2
n = 3
n = 4
n = 5
Process 15521 exited with status = 0 (0x00000000)
quit
$

As you can see from the above, the prompt is being printed straight after the 'Process X launches: ...' line where it should wait until the target's stopped (where the 'quit' command's been entered above).

Hope this helps!

Prompt handling was fixed a couple months back.

mentioned in issue llvm/llvm-bugzilla-archive#17228