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:
via the Activity Monitor's send signal to process feature
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.
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.
Related
I would like to debug a C++ program in VSCode. The problem is this program is run as part of a large and messy build system that spawns many processes and prepares input for the program. In other words if I run:
./do the_task
It will compile a load of C++, generate some input and eventually - through several layers of Bash, Python and Makefiles - run something like this:
/very/long/path/to/the_task --lots --of --arguments /very/long/path/to/generated_input.xml
I'd like to debug that process using VSCode/GDB, in such a way that I can
Set breakpoints in the_task.cpp
Just click "Start debugging" with the launch.json set to run do the_task
Unfortunately that doesn't work because by default GDB doesn't follow child processes. You can tell it to but then it will halt the parent process so that only a single process runs at a time. That causes everything to get stuck at some point in my case.
Some ideas I've had:
Is there a way to tell GDB to run a script when a new inferior (process) starts, check the executable name and then detach from the child if it doesn't match?
I could create a proxy GDB/MI wrapper that pretends to VSCode that the program has been started (so the connection doesn't time out), and then when we get to running /very/long/path/to/the_task prefix it with gdb --interpreter=mi and forward on all of the cached commands (to set breakpoints etc.) This seems like quite a lot of work and quite hacky so I'm not sure I like it.
Prefix /very/long/path/to/the_task with gdbserver. Then I can connect to it from VSCode. This is definitely the simplest and most obvious solution but the UX sucks - you have to manually start the command, then wait, then click "start debugging". Plus you're inevitably going to run into port reuse annoyances.
3, but write a custom VSCode extension that automatically starts debugging when it detects gdbserver has started. I've done this for Python debugging so it does work but there are some minor annoyances (e.g. if you restart VSCode and it restores a terminal session it doesn't work). Also it's a fair amount of work.
Is there an obvious solution I'm missing?
I used Msys1 for many years and was used to CTRL+C for killing processes that I start within my shell.
After updating from Msys1 to Msys2 CTRL+C does not work any more.
For example: I start "make" press CTRL+C. Shell prompts to finished and enables typing more commands, but make.exe is still running+working.
Result of my analysis:
In Msys1: shell.exe(12345) starts make.exe(23456) and make.exe(23456) has the information, that its parent is (12345).
In Msys2: shell.exe(12345) starts make.exe(23456) and make.exe(23456) has the information, that its parent is the (34567), which is not alive anymore. So I guess Msys2 uses an additional process for starting subprocesses.
I tried bash.exe, shell.exe, mintty.exe,... all seems to have the same problems.
Content I found searching
:
This ticket just focuses on missing signal types -> I don't care about that.
https://sourceforge.net/p/msys2/tickets/135/
The issue in this mailing list seems to be near my problem, but I do not understand what I should change, or if the change can only be made within the msys2 implementation. (What is CREATE_NEW_PROCESS_GROUP? and how to change it):
https://www.cygwin.com/ml/cygwin/2012-08/msg00062.html
Kindest regards
Luke
It looks like mintty provides the default terminal for MSYS2 (note that this is different from the shell that is run within). If so, then the "Ctrl+C kills native (e.g. MSYS2 compiled) programs abruptly rather than sending a catchable signal" problem is the same one as described over on https://superuser.com/questions/606201/how-to-politely-kill-windows-process-from-cygwin and the MSYS2 wiki porting FAQ.
If what you're attempting works when you are using Windows' default terminal (e.g. when using cmd.exe from the start menu) then this is the issue you're seeing.
It is in fact suggested in the other answer but you can just run each program by winpty.exe which will make CTRL-C working again.
Gameconqueror can update the variables it found continuously without stopping the program it's tracing. But as I know you have to use ptrace() to gain access of the specified program and when you do that it automatically stops the debuggee. But somehow Gameconqueror manages to do it's job without interrupting the debuggee(and it updates itself like every half second).
I think if Gameconqueror can do it, also gdb should be able to do it. I tried to enter some commands after continuing the debuggee, gdb doesn't give any error but also doesn't display anything. I'm very confused.
You need to make use of asynchronous mode within gdb. This is documented here:
https://sourceware.org/gdb/onlinedocs/gdb/Background-Execution.html#Background-Execution
For example:
(gdb) continue &
Will continue your program and then immediately return to the command prompt, allowing you to issue further commands while your program is still running.
If you want to stop your program you need to use the interrupt command, as the usual Ctrl+c will not work.
I have a process that is already running, and I want to debug it with GDB. I've been using
gdb --pid $PID
However, when I do this, the process pauses. I'd like to attach to the process without pausing it, and look around in its memory while it's still running. Is this possible? Alternatively, is there a way to "fork" the process so that I can look at its memory, without stopping/pausing the process?
There's no way in gdb to attach without some sort of pause.
The Linux kernel provides some support for this via PTRACE_SEIZE, but gdb doesn't use this yet. There's a bug in bugzilla you can track, "Bug 15250 - use PTRACE_SEIZE and PTRACE_INTERRUPT"
Meanwhile you could try setting gdb into "observer mode". Then you could attach and use continue & to continue the process in the background. You may need to set various settings, like target-async, depending on the gdb version.
I am not totally certain if this will work. It is worth a try. Note that there is a window in which the program will be paused. This is unavoidable right now.
Maybe a simple question.
When I attach to a process, I run "continue" to make it continue to run.
Then I want to some other job like "add-symbol-file" with need not interactive with target process, but after the "continue" command, the gdb console will block, so I can not do any action before I break the process.
Is there any way that I can do such thing without suspend the process?
Make sure the console which gdb is running in has keyboard focus, then press CTRL-C. This will usually result in a SIGINT signal to be sent to gdb.
With me, GDB then pauses execution of the program and accepts user commands again.
Should the CTRL-C not work (perhaps different config) try to send the signal manually:
Find out the pid of gdb such as with command top and then send a SIGINT to gdb:
kill -2 pidhere
Until recently you couldn't do what you want, but the newly released
version 7.0 of gdb has what is called a "non-stop" mode, in which the
gdb prompt / console can be used while the program is running.
See http://sourceware.org/gdb/current/onlinedocs/gdb_6.html#SEC47
You may want to study the remote gdb mechanisms a bit for something like that.
For understanding the debugging process more read this short article.