an annoying runtime bug of lldb on redhat enterprise linux 6.3 with gcc 4.8.2

Hi, all

A few days ago I built lldb 3.3 release on our workstation with redhat enterprise linux 6.3 x86_64 (gcc verison 4.8.2). At the very beginning, lldb seemd to work and I debugged small native programs. Still, the bug showed itself randomly as follows:

  1. at first, “(lldb)” prompt is missing and input from keyboard is not printed out, which means whatever I type, I can not read them on screen. Still, lldb corresponds to the command I type on condition that I input them correctly. lldb gives tips if I type a wrong command string.

  2. if situation mentioned above appears and I type “quit” to exit lldb, a segmentation fault (core dumped) happen. I debug lldb with gdb-7.6.1, and track the segmentation fault source to a message “Program received signal SIGSEGV, segmentation fault. 0x3b55c07fc3 in pthread_join () from /lib64/libpthread.so.0”.

Since I am not familiar with multi-thread programming, I can not dig any further. Do you guys have Any clue?

Thanks beforehand.

Hi Yang,

1. at first, "(lldb)" prompt is missing and input from keyboard is not
printed out, which means whatever I type, I can not read them on screen.
Still, lldb corresponds to the command I type on condition that I input them
correctly. lldb gives tips if I type a wrong command string.

I see similar, but not identical, symptoms on Linux. I think what I
type is always echoed, but the prompt randomly decides not to appear.
There's clearly something odd in how it's interacting with libedit
(does ldd report it using the same readline-substitute on RedHat?),
but I'm not sure where to start either.

2. if situation mentioned above appears and I type "quit" to exit lldb, a
segmentation fault (core dumped) happen. I debug lldb with gdb-7.6.1, and
track the segmentation fault source to a message "Program received signal
SIGSEGV, segmentation fault. 0x3b55c07fc3 in pthread_join () from
/lib64/libpthread.so.0".

This one should be fixed in 3.4 (or any build after about June). It
had the right combination of annoying and easy to track down.

Cheers.

Tim