0
votes

I'm trying to use LLDB to debug a program on OSX and control-C is not working to stop the program. It seems to be in an infinite loop and I want to see where it is; hence I can't just use breakpoints. This used to work for me -- I used to be able to control-C to send SIGINT and LLDB respected it and stopped the program on this computer with this same toolchain. I see the ^C in the terminal but it's being ignored. I also tried to send the signal to the lldb process in two other ways:

  1. via the Activity Monitor's send signal to process feature
  2. via pkill -SIGINT lldb

However, that didn't work either. control-z DOES work to stop lldb, on the other hand but that's not what I need (which is to be able to inspect program state).

I tried this both with the built-in Terminal app as well as iTerm2 - but I'm seeing the same behavior on both.

Version info

lldb --version
lldb-1000.11.38.2
  Swift-4.2

I think this is the version of lldb installed with XCode. It's possible that an upgraded XCode (which I don't use directly) broke this.

Update: I'll add that variable names are not auto-completing for me in lldb either -- I'm pretty sure this also used to work. For example, if I type p and then start typing a variable name, it doesn't tab-complete. I'm adding this update in case it may be related.

1
are you running your process from within lldb, or attaching to it. I think "p" tab completion may? work in Xcode's debugger console window, but it does not work in command line lldb - it's an arbitrary C++/etc expression and lldb doesn't parse the contents of it. Other variable printing mechanisms like "v" will tab complete. Fwiw that lldb version is a bit old, from maybe Sep-Nov 2018. Current released Xcode will give you lldb-1001.something; the Xcode that will be released this fall will give you lldb-1100.something. - Jason Molenda
Did you try sending the SIGINT the process you are debugging using methods 1 & 2 above? If those don't work, then it may be that the process you are debugging is blocking SIGINT. Maybe try sending some other signal (like SIGUSR1)? That might not be blocked, and then as long as you use process handle SIGUSR1 -p 0 so the signal isn't forwarded, you won't change the program execution. - Jim Ingham
Thanks. I was able to fix this. A couple of interesting learnings: 1) with the old version (1000.11.38.2), it respected SIGINT when I didn't run with a command script (which simply contained run) but ran manually; 2) when I upgraded to 1001.0.13.3, it just worked. It's moot now with the upgrade, but it seems the old version with a command script somehow blocked SIGINT. - Kulluk007

1 Answers

1
votes

See comment above -- it seems that this was a bug with lldb version 1000.11.38.2 when using a command script that contained run in it. Upgrading and/or not using a command script with run allows the program to be interrupted.