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.
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'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.
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.
I have an application made with matlab compiler.
I want to do some shutdown activities whenever it ends. As it seems to be impossible to catch signals in matlab (or I'm not able to), I checked to use onCleanup (Matlab: Is it possible to create signal handlers (.m scripts)). It is working within matlab (native), but not within the compiled application.
I tried to end the application with CTRL-C and with taskkill (which only work with /f). In both cases the onCleanup-method was NOT executed.
For testing purposes here
function sigtest(varargin)
remainder=onCleanup(#()save('exit.mat'));
b=1;
while true
disp(datestr(now));
a=rand(round(5*b));%to be saved
pause(10);
b=a(1);
end
my source code, which I compiled via mcc -m -v sigtest.m.
As onether try, I inserted the lines
myexiter=addlistener(System.AppDomain.CurrentDomain,'ProcessExit',...
#(a,b)save('listexit.mat'));
after line 2, but also this .NET-Event is not working.
If you're registering shutdown activities within M-code, they're only going to work on a graceful shutdown of the process. The taskkill /f command will do a "forceful" shutdown, which I think will terminate the process immediately. The Matlab interpreter won't get a chance to run whatever cleanup code is still pending. I think Ctrl-C on a console application (which the compiled sigtest.m will be running as) will have the same effect. Same applies to the .NET-Event: if you forcefully kill the process, that callback never gets a chance to run.
If you want on-exit code, or any other cleanup stuff, to run, you need to find a way for the program to find out when it should exit and initiate a more graceful shutdown itself. For example, in your sigtest example, you could check stdin at the end of every pass through the loop, see if the user has typed 'quit', and if so call exit(). Then your onCleanup stuff should run.
In a GUI compiled Matlab application, this is more straightforward; you have GUI controls to exit the application. I don't know what the canonical way is to make a console compiled Matlab application responsive to user exit requests, or if there even is a good one. You might want to make this a GUI app if you think the user might want to request a graceful abort of its operation.
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.