just me, or lldb 3.4 is very buggy?

hi,

i am using Ubuntu 13.10, and installed lldb 3.4 from its official repo.

i am running this lldb 3.4, but it seems very buggy, even with simple commands

(1) the breakpoint doesnt seem to work, as my application doesnt stop at breakpoint, as in below session.

(lldb) b main
Breakpoint 1: where = buggy`main, address = 0x0804847d
(lldb) r aaa
Buffer : aaa
Process 3612 launched: ‘./buggy’ (i386)
Process 3612 exited with status = 0 (0x00000000)

(2) many commands doenst return to the prompt, but seems to hangup.

you can try this by loading any application ($ lldb ./myapp), the type “br l”. the prompt (lldb) would not show up after the command. you can continue to type after that, except what you type do not show on terminal, however.

i am wondering why lldb 3.4 still has trivial basic bugs like this? is this fixed in latest code in repo?

thanks,
Jun

Hi Jun,

Sorry you had problems using lldb. I generally use LLDB (built from source) on my Ubuntu 12.04 system.

There have been problems here and there but it mostly works. Please try from the source and let us know

If you still face the problems.

Regards,

Abid

You will need to update the installed libedit on your machine. "libedit" is the line reader program we use to get commands and the default version on most linux's is quite old and out of date.

hi,

i am using Ubuntu 13.10, and installed lldb 3.4 from its official repo.

i am running this lldb 3.4, but it seems very buggy, even with simple commands

(1) the breakpoint doesnt seem to work, as my application doesnt stop at breakpoint, as in below session.

(lldb) b main
Breakpoint 1: where = buggy`main, address = 0x0804847d
(lldb) r aaa
Buffer : aaa
Process 3612 launched: './buggy' (i386)
Process 3612 exited with status = 0 (0x00000000)

(2) many commands doenst return to the prompt, but seems to hangup.

you can try this by loading any application ($ lldb ./myapp), the type "br l". the prompt (lldb) would not show up after the command. you can continue to type after that, except what you type do not show on terminal, however.

i am wondering why lldb 3.4 still has trivial basic bugs like this?

Update to the latest libedit and see how many problems that solves for you.

is this fixed in latest code in repo?

With a new libedit and the top of tree LLDB, you will have a much better experience.

Let us know how things go.

Greg Clayton

You can also try using
http://llvm.org/apt/
which provides Ubuntu snapshot packages of the 3.5 dev tree.

S

Ubuntu saucy (13.10) has libedit v3.1-20130712. Not sure it is the
issue here...

Sylvestre

Hi Jun,

Could you file a bug here and attach your source? Include how you compile it so we make sure we’re all on the same page to reproduce it. Then we can see what’s going on.

Thanks for reporting it!

Sincerely,
Todd Fiala

hi,

i got lldb 3.5 from llvm.org/apt, and it is a bit better: it no longer has issue with libedit, it seems.

however, it crashes all the time. you can easily reproduce it like below:

$ lldb-3.5 ./test
Current executable set to ‘./test’ (i386).
(lldb) b main
Breakpoint 1: where = test`main, address = 0x0804847d
(lldb) r
Segmentation fault (core dumped)

“test” can be any program. in my case, it is just a “hello world” program, written in C.

again, this is on Ubuntu 13.10 32bit. please try it, and confirm this is indeed a bug.

at this current status, lldb is really unusable :-((

thanks.

Jun

Hi Jun,

Thanks again for the report.

I’m hopping over to Ubuntu 13.10 and will have a look at this. It would definitely be helpful to know a few things (which I’m going to have to guess about here):

  • What compiler are you using? gcc or clang?
  • What flags did you pass to the compiler when you compiled? Was it a debug build? Was it optimized?

I’ll file a bug if I’m able to cause a seg fault. Yesterday I had a check-in that fixed a seg fault under Linux - not sure if that’s something you were hitting.

I’ll post what I see.

-Todd

Hi Jun,

Thanks again for the report.

I'm hopping over to Ubuntu 13.10 and will have a look at this. It would
definitely be helpful to know a few things (which I'm going to have to
guess about here):
* What compiler are you using? gcc or clang?

i am using default CC, which is gcc

* What flags did you pass to the compiler when you compiled? Was it a
debug build? Was it optimized?

it is also default compiler option. for example, with helloworld.c program,
i simply compiled it with (without Makefile):

     $ make helloworld

I'll file a bug if I'm able to cause a seg fault. Yesterday I had a
check-in that fixed a seg fault under Linux - not sure if that's something
you were hitting.

I'll post what I see.

awesome, please keep us updating!

thanks,
Jun

Here’s what I’m seeing on Ubuntu 12.04 x86_64 (I’ll hop over to Ubuntu 13.10 in a moment to see what it shows), using gcc 4.8.2:

Here is my hello.c:

#include <stdio.h>

int main(int argc, char **argv)
{
printf(“Hello, world\n”);
return 0;
}

Here is the output from compiling and running lldb:

tfiala@tfiala2:~/lldb/samples/hello$ gcc -g -O0 -o hello hello.c
tfiala@tfiala2:~/lldb/samples/hello$ ./hello

Hello, world

the following is my top of tree build from lldb as of about 12 hours ago

tfiala@tfiala2:~/lldb/samples/hello$ ~/lldb/svn/lgs/build2/Debug+Asserts/bin/lldb
(lldb) target create ./hello
Current executable set to ‘./hello’ (x86_64).
(lldb) b main
Breakpoint 1: where = hello`main + 15 at hello.c:5, address = 0x00000000004004df
(lldb) r
Process 11433 launching
Process 11433 stopped

  • thread #1: tid = 11433, 0x00007faad38206b0, name = ‘hello’, stop reason = trace
    frame #0: 0x00007faad38206b0
    → 0x7faad38206b0: movq %rsp, %rdi
    0x7faad38206b3: callq 0x7faad3824010
    0x7faad38206b8: movq %rax, %r12
    0x7faad38206bb: movl 0x2215ff(%rip), %eax
    (lldb) Process 11433 launched: ‘./hello’ (x86_64)
    Process 11433 stopped
  • thread #1: tid = 11433, 0x00000000004004df hellomain(argc=1, argv=0x00007fffa93f3ba8) + 15 at hello.c:5, name = 'hello', stop reason = breakpoint 1.1 frame #0: 0x00000000004004df hellomain(argc=1, argv=0x00007fffa93f3ba8) + 15 at hello.c:5
    2
    3 int main(int argc, char **argv)
    4 {
    → 5 printf(“Hello, world\n”);
    6 return 0;
    7 }
    (lldb)

I’ll try it on Ubuntu 13.10 x86_64 next. That one will be with a stock system + packages for build-essential, libedit-dev, libpython-dev and swig (I think that’s it).

-Todd

Here's what I'm seeing on Ubuntu 12.04 x86_64 (I'll hop over to Ubuntu
13.10 in a moment to see what it shows), using gcc 4.8.2:

so it seems you dont see any segfault??

sorry if i forgot: my Ubuntu 13.10 is 32bit.

thanks,
Jun

Here is my hello.c:

#include <stdio.h>

int main(int argc, char **argv)
{
    printf("Hello, world\n");
    return 0;
}

Here is the output from compiling and running lldb:

tfiala@tfiala2:~/lldb/samples/hello$ gcc -g -O0 -o hello hello.c
tfiala@tfiala2:~/lldb/samples/hello$ ./hello
Hello, world
# the following is my top of tree build from lldb as of about 12 hours ago
tfiala@tfiala2:~/lldb/samples/hello$
~/lldb/svn/lgs/build2/Debug+Asserts/bin/lldb
(lldb) target create ./hello
Current executable set to './hello' (x86_64).
(lldb) b main
Breakpoint 1: where = hello`main + 15 at hello.c:5, address =
0x00000000004004df
(lldb) r
Process 11433 launching
Process 11433 stopped
* thread #1: tid = 11433, 0x00007faad38206b0, name = 'hello', stop reason =
trace
    frame #0: 0x00007faad38206b0
-> 0x7faad38206b0: movq %rsp, %rdi
   0x7faad38206b3: callq 0x7faad3824010
   0x7faad38206b8: movq %rax, %r12
   0x7faad38206bb: movl 0x2215ff(%rip), %eax
(lldb) Process 11433 launched: './hello' (x86_64)
Process 11433 stopped
* thread #1: tid = 11433, 0x00000000004004df hello`main(argc=1,
argv=0x00007fffa93f3ba8) + 15 at hello.c:5, name = 'hello', stop reason =
breakpoint 1.1
    frame #0: 0x00000000004004df hello`main(argc=1,
argv=0x00007fffa93f3ba8) + 15 at hello.c:5
   2
   3 int main(int argc, char **argv)
   4 {
-> 5 printf("Hello, world\n");
   6 return 0;
   7 }
(lldb)

I'll try it on Ubuntu 13.10 x86_64 next. That one will be with a stock
system + packages for build-essential, libedit-dev, libpython-dev and swig
(I think that's it).

-Todd

Here's what I'm seeing on Ubuntu 12.04 x86_64 (I'll hop over to Ubuntu
13.10 in a moment to see what it shows), using gcc 4.8.2:

so it seems you dont see any segfault??

sorry if i forgot: my Ubuntu 13.10 is 32bit.

to make sure we are on the same page, can you install lldb 3.5 from
llvm.org/apt/, and try again ?

thanks,
Jun

Here is my hello.c:

#include <stdio.h>

int main(int argc, char **argv)
{
    printf("Hello, world\n");
    return 0;
}

Here is the output from compiling and running lldb:

tfiala@tfiala2:~/lldb/samples/hello$ gcc -g -O0 -o hello hello.c
tfiala@tfiala2:~/lldb/samples/hello$ ./hello
Hello, world
# the following is my top of tree build from lldb as of about 12 hours ago
tfiala@tfiala2:~/lldb/samples/hello$
~/lldb/svn/lgs/build2/Debug+Asserts/bin/lldb
(lldb) target create ./hello
Current executable set to './hello' (x86_64).
(lldb) b main
Breakpoint 1: where = hello`main + 15 at hello.c:5, address =
0x00000000004004df
(lldb) r
Process 11433 launching
Process 11433 stopped
* thread #1: tid = 11433, 0x00007faad38206b0, name = 'hello', stop reason =
trace
    frame #0: 0x00007faad38206b0
-> 0x7faad38206b0: movq %rsp, %rdi
   0x7faad38206b3: callq 0x7faad3824010
   0x7faad38206b8: movq %rax, %r12
   0x7faad38206bb: movl 0x2215ff(%rip), %eax
(lldb) Process 11433 launched: './hello' (x86_64)
Process 11433 stopped
* thread #1: tid = 11433, 0x00000000004004df hello`main(argc=1,
argv=0x00007fffa93f3ba8) + 15 at hello.c:5, name = 'hello', stop reason =
breakpoint 1.1
    frame #0: 0x00000000004004df hello`main(argc=1,
argv=0x00007fffa93f3ba8) + 15 at hello.c:5
   2
   3 int main(int argc, char **argv)
   4 {
-> 5 printf("Hello, world\n");
   6 return 0;
   7 }
(lldb)

I'll try it on Ubuntu 13.10 x86_64 next. That one will be with a stock
system + packages for build-essential, libedit-dev, libpython-dev and swig
(I think that's it).

-Todd

Hi guys,

I notice that Jun is on 32-bit and I can also confirm that I haven’t found it possible to get lldb working under 32-bit Linux. LLDB can’t currently be compiled with clang right now due to this issue:

http://llvm.org/bugs/show_bug.cgi?id=18311

And compiling with gcc (4.8.1 in my case) results in this assertion failure when trying to debug anything:

http://llvm.org/bugs/show_bug.cgi?id=17802

Hope that helps,
Andrew

Very helpful, thanks Andrew.

Jun - seems much more likely this is related to the 32-bit rather than the Ubuntu 13.10 part. (I am still building the latest lldb on Ubuntu 13.10 right now, but it is a 64-bit version).

I’ll eventually need 32-bit working on Ubuntu if lldb goes into the Android AOSP tree and if we still use 32-bit host tools, so I’ll have a look at what’s up with that.

Any chance you can move to 64 bit in the meantime, Jun?

Very helpful, thanks Andrew.

Jun - seems much more likely this is related to the 32-bit rather than the
Ubuntu 13.10 part. (I am still building the latest lldb on Ubuntu 13.10
right now, but it is a 64-bit version).

I'll eventually need 32-bit working on Ubuntu if lldb goes into the
Android AOSP tree and if we still use 32-bit host tools, so I'll have a
look at what's up with that.

Any chance you can move to 64 bit in the meantime, Jun?

yes i can if there is no alternative, but i would not want to do that if
32bit works for me.

so please support 32bit lldb, as it is still the main environment for lots
of people.

thanks,
Jun

Just for posterity’s sake, I did run the hello world test on Ubuntu 13.10 (x86_64 - so not 32-bit), top of tree lldb, and it did work. I know this isn’t the 32-bit case, I just wanted to show it working on Ubuntu 13.10 in 64-bit mode. Same hello.c as before, this time with gcc 4.8.1 as distributed with Ubuntu 13.10:

create a.out

tfiala@ubuntu:~/work/samples/hello$ gcc -g -O0 hello.c

run my top of tree lldb that I just built from lldb as of svn r200548.

tfiala@ubuntu:~/work/samples/hello$ ~/work/lgs/build/Debug+Asserts/bin/lldb
(lldb) target create a.out
Current executable set to ‘a.out’ (x86_64).
(lldb) b main

Breakpoint 1: where = a.out`main + 15 at hello.c:5, address = 0x000000000040053c
(lldb) run
Process 11621 launching
Process 11621 stopped

  • thread #1: tid = 11621, 0x00007f428f3a7630, name = ‘a.out’, stop reason = trace
    frame #0: 0x00007f428f3a7630
    → 0x7f428f3a7630: movq %rsp, %rdi
    0x7f428f3a7633: callq 0x7f428f3aafa0
    0x7f428f3a7638: movq %rax, %r12
    0x7f428f3a763b: movl 0x2216ef(%rip), %eax
    (lldb) Process 11621 launched: ‘/home/tfiala/work/samples/hello/a.out’ (x86_64)
    Process 11621 stopped
    (lldb) * thread #1: tid = 11621, 0x000000000040053c a.outmain(argc=1, argv=0x00007fff68b12a38) + 15 at hello.c:5, name = 'a.out', stop reason = breakpoint 1.1 frame #0: 0x000000000040053c a.outmain(argc=1, argv=0x00007fff68b12a38) + 15 at hello.c:5
    2
    3 int main(int argc, char **argv)
    4 {
    → 5 printf(“Hello, world\n”);
    6 return 0;
    7 }
    (lldb)

I did assign myself the 32-bit Ubuntu 13.10 issue for gcc-built lldb. I’ll have a look at that:
http://llvm.org/bugs/show_bug.cgi?id=17802

i tried llvm-3.4 on Ubuntu 13.10-64bit, and have this issue:

  • immediately after lldb shows the prompt (lldb), i entered “b main”

  • then to see the list of breakpoints, i entered “br l”. this command shows 1 breakpoint (this is expected), but doesnt return to the prompt after that.

i installed lldb-3.5 from llvm.org/apt/, and this problem was fixed.

is there any chance to have lldb-3.5 with upcoming Ubuntu 14.04 to replace lldb-3.4, which is so buggy that it is unusable even for basic usage?

thanks,
Jun

Do we have any Debian/Ubuntu maintainers on this list? They can tell you what they plan on integrating. We are making a number of changes/fixes that they’d likely want to pick up, but ultimately it is up to them where they stabilize.

Do we have any Debian/Ubuntu maintainers on this list?

This is probably Sylvestre.

They can tell you
what they plan on integrating. We are making a number of changes/fixes that
they'd likely want to pick up, but ultimately it is up to them where they
stabilize.

Cheers,
Tobias

If you provide me a patch, I will apply it to 3.4 for 14.04. With the plan to have stable release (ie 3.4.1), we could also see the patch added to this release. Cheers, S