Different Behavior between Terminal and GUI simulated terminal

Hi,

I got different behavior between run lldb under regular terminal

And GUI simulated terminal (posix_openpt or pipe based).

In the regular terminal:

(lldb) run

Process 10992 launched: ‘…’

Process 10992 stopped

Thread …

In the GUI, If I run the same thing, I got

(lldb) run

Process 10992 launched: ‘…’

(lldb) Process 10992 stopped

Thread …

There already is (lldb) after the first line.

My lldb is 179.5

Could anybody let me know why there is this difference?

And How to switch to the regular mode?

Thanks,

Yin

Did you launch the two processes in the same way in both cases? It looks like in the first instance lldb is running synchronously, and in the second instance asynchronously. I sent a note to the list a couple of days ago describing when lldb uses the two modes, check that and see if it explains what you are seeing. Otherwise, this may be some bug in the input driver?

Jim

Hi Jim,

I double checked that there is only one lldb launched for sure.
I did ps -ax | grep lldb, there is only one process listed.

Thanks,

Yin

Sorry, that's not what I meant. The message I was referring to was in the thread "Async vs. sync" and I said:

The way the command line lldb works at present is that if you attach to a process (or run it with the stdio put to another terminal via the -tty option) then lldb runs in asynchronous mode. E.g.:

lldb -n Calendar

Attaching to process with:
   process attach -n "Calendar"
Process 211 stopped
Executable module set to "/Applications/Calendar.app/Contents/MacOS/Calendar".
Architecture set to: x86_64-apple-macosx.
(lldb) c
Process 211 resuming

I still have a command prompt, so for instance I can check status and interrupt

(lldb) process status
Process 211 is running.
(lldb) process interrupt
Process 211 stopped
* thread #1: tid = 0x0703, function: mach_msg_trap , stop reason = signal SIGSTOP
   frame #0: 0x00007fff8e531686 libsystem_kernel.dylib`mach_msg_trap
libsystem_kernel.dylib`mach_msg_trap + 10:
-> 0x7fff8e531686: ret
  0x7fff8e531687: nop

So we are running the command interpreter in "asynchronous" mode.

So you see you will either get a prompt right away or not depending on how you start up the process you are debugging. Note that if you use the --tty option or the --no-stdio when you launch a process you will also be in asynchronous mode. But if you do an ordinary "process launch" with no options, you won't get a prompt till the process stops.

Jim

I’ve noticed this same bug myself, and actually spent a while this week trying to fix it (with no luck).

The problem is simply a threading race condition, which manifests sometimes. You can usually (on Linux at least) trigger it by just doing a ‘run’ repeatedly until it happens.

It’s because the process’s input reader is created asynchronously on a thread, so isn’t guaranteed to be at the top of the input stack at the time the ‘run’ command has finished. So the driver may or may not try to refresh the prompt.

I don’t have a fix for this I’m afraid.

Also, regarding the original problem, it sounds to me like you’re trying to capture the lldb output so you can build a debugger interface on top (like GDB interfaces often work). For what it’s worth, this is a really bad idea. lldb has a C++ and Python API which are much better suited for that kind of thing.

compose-unknown-contact.jpg

Hi Richard,

Thank you for digging down the detail for this problem.

Hope this problem could be fixed soon.

Yes, we are porting our debugger GUI for GDB to support

lldb. Its existing framework is based on capturing output.

I am writing some python commands to create a bridge to

generate parser friendly output. I am working feature

by feature. I hope this way can work for all features.

Thanks,

Yin

compose-unknown-contact.jpg

I agree with Richard, parsing command output to drive lldb is a way that leads to madness. The tools that do this using gdb at least have annotate and/or the MI output format from gdb's command line to help them out, and even then it's a huge pain (and I speak as one who has spent a number of years doing this.) But I would be very resistant to accepting patches that would add an annotate or MI-like feature to lldb's command interpreter. That would needlessly complicate the Command Interpreter code, and seems like wasted effort when we've gone to a lot of trouble to provide the SB API's so that programmatically driving lldb will be convenient and supportable.

Is there any compelling reason not to use the SB API's?

Jim

Hi Jim

There is no special reason not to use the SB API.
I understand it is very powerful and convenient.
If I create a new GUI from scratch, I will definitely
go for API directly. Because our GUI framework is already there
and we want to one framework supports both gui and lldb,
I picked a way to minimize the change to our existing
Framework.

Now when our GUI launches lldb, it will at first load
A python script that defines a series of new commands.
Those new commands simulate the usage to API instead of
calling API directly. Hope this way can handle all
Features I need.

Thanks,

Yin