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.
Related
An unidentified process on macOS periodically creates an empty temporary file in my Downloads folder but doesn't remove it later
I managed to figure out that immediate culprit is mktemp, but I want to understand which process calls it
I figure that I can use $ lldb > process attach -name mktemp -watifor to attach to mktemp when it's being launched, but can't figure out how to know who called it in first place
Is there any solution whether with or without lldb to know it?
That's actually a little trickier than you might think.
You can find the parent process of a given process on macOS easily by running ps -j <PID> though Terminal. The parent pid is the third column in the output. Or Activity Monitor has a hierarchical display that shows these relationships graphically.
lldb prints the pid of the process it is attaching to when it attaches, or you can find it in the output of the lldb command target list. So that's easy to find...
However, for technical reasons, when the debugger attaches to a process that process gets "reparented" by the kernel to the debugger. So if you ask a process running under lldb who its parent process is, the answer will always be "debugserver" - which is lldb's debugger stub. And there isn't an easy way to see what the original parent was.
I got this to work, though this is a bit of a hack. You want to suspend the process you are debugging so it doesn't exit on you, then detach from it so it gets reparented back to the real parent. So:
In lldb, run:
(lldb) expr (void) task_suspend((void *)mach_task_self())
Since that suspended the task before returning, the command won't actually complete. So
Use ^C in the lldb console to interrupt the expression evaluation. The target process is already suspended so this will just cancel the task_suspend return code.
Now detach:
(lldb) detach
When you do that the mktemp process will be reparented by the system back to its original parent,
Now you can run ps -j in Terminal and find the process you are looking for, and it will be the original parent.
If you need to get the process running again, attach to it with lldb again and call task_resume with the same arguments as you called task_suspend above.
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.
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.
I am writing a normal, innocent C++/Qt program in Windows 7/MinGW.
It is the second time in two days that after closing the program the executable remains among the active processes, and there is no way to kill it (I try both from the command line and from Windows Task Manager).
One inconvenience is that I cannot re-link my code, because the binary code cannot be overwritten, being running.
The reason is that the executable was running under the control of the debugger, and this protected the process against any attempt to kill it. Stopping it through the debugger has been successful.
I did not know that the debugger could shield a process from any external attempt to kill it so well...