I know we could use the handle signal command in gdb to make it pass the SIGINT signal to the program. Is there a way to do the same while using the debugger in vs code?
In the Debug Console of vs code write:
-exec handle SIGINT pass
-exec handle SIGINT nostop
Open another terminal.
ps -eaf |grep <Proc-Name> // find the PID
kill -s SIGINT PID_OF_PROCESS
Get back to VS Code
Now you can see and use the stacktrace etc.
Related
We're running squid from with gdb - that way we can automatically generate backtraces for debugging.
backtrace=`mktemp`
gdb -q -x /etc/service/squid3/gdbcommands /usr/sbin/squid 2>&1 >$backtrace
/usr/bin/mail -s "`hostname`: Squid was restarted (backtrace)" someaddress#charite.de < backtracetrace
rm $backtrace
/etc/service/squid3/gdbcommands contains:
set args -NsYC
handle SIGPIPE pass nostop noprint
handle SIGTERM pass nostop noprint
handle SIGUSR1 pass nostop noprint
handle SIGHUP pass nostop noprint
handle SIGSEGV stop
handle SIGABRT stop
run
set print pretty
backtrace full
generate-core-file
quit
But, every now and then, squid is "just" being stopped & restarted, with no crash being involved at all. In that case I'm still getting an email containing:
Reading symbols from /usr/sbin/squid...done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 1 (process 57867) exited normally]
/etc/service/squid3/gdbcommands:10: Error in sourced command file:
No stack.
(gdb) quit
And of course there's no stack, since the program exited ok.
How can I change my gdbcommands file to avoid this?
This can be done using either Python or the gdb CLI. Since the CLI is a bit simpler, when possible, I'll sketch that approach.
First, you might as well only create a core file on a bad exit. And, we'll use the gdb exit code later, so let's arrange for that to tell the calling script what happened.
Where your current script says:
backtrace full
generate-core-file
quit
... instead use:
if !$_isvoid($_exitsignal) || (!$_isvoid($_exitcode) && $_exitcode != 0))
backtrace full
generate-core-file
quit 0
end
quit 1
Then your calling script can check the exit code of gdb:
if gdb your args here; then
mail results
fi
I want to debug a c program with gdb which is invoked by shell script. In this shell script , there are lot of things done and many environment variables are set.
This shell script is invoked by boost::process::launch from a c++ program.
I can change c++ program, shell script, and the c program itself, but can't change the architecture of this flow.
Is there any way , so that i can use gdb to debug the program.
If there is no solution, is there a way to dump all environment settings before launching shell script, so that i can launch same script with these settings to debug it later. I will prefer a portable and long term solution.
Two easy options:
Attach gdb after the program has started with gdb -p <pid of process> if it doesn't matter to stop it at a specific point.
Insert a raise(SIGSTOP); in the C program where you want it to stop. Once the process is stopped, attach gdb as in 1, set any breakpoints you need and then send the process a SIGCONT signal (kill -CONT <pid of process>) to cause it to continue.
I'm trying to write a program which, at some point, needs to invoke an external application via the system and wait until that other executable finishes. I pretty much want a C++ version of the python subprocess.call(...) method. I know that system() can invoke a command via the shell, but I don't know if it is able to block until the commands terminate. Anyone know the right way to do this?
I'm writing this for a Linux system, but if possible, I'd like it to be portable. Anyway, any help would be appreciated.
system() waits for the command to finish:
http://linux.die.net/man/3/system
system() executes a command specified in command by calling /bin/sh -c
command, and returns after the command has been completed. During
execution of the command, SIGCHLD will be blocked, and SIGINT and
SIGQUIT will be ignored.
The popen command should work nicely for you: http://linux.die.net/man/3/popen
I am coding in C++ in Linux. I have handled the ctrl C signal so that I could clean up all the resources upon exit. However, I have the problem when I run gdb. Ctrl C is also the stopping of the gdb command. Hence, how do I send the ctrl C to my programme so that I could test my written resource clean up code?
Thanks.
At gdb's command prompt:
signal SIGINT
You can tell GDB to pass the signal through to your program and not stop:
(gdb) handle SIGINT pass nostop
I'm trying to debug a server I wrote with gdb as it segfaults under very specific and rare conditions.
Is there any way I can make gdb run in the background (via quiet or batch mode?), follow children (as my server is a daemon and detaches from the main PID) and automatically dump the core and the backtrace (to a designated file) once the program crashes?
Assuming you have appropriate permissions, you can have gdb attach to any process. You can do it on the command line with:
gdb /path/to/binary _pid_
or from within gdb with the attach command:
attach _pid_
So, once your daemon has started, you can use either of these techniques to attach to the final PID your daemon is running as. Attaching gdb stops the process which you are tracing so you will need to issue a "continue" to restart it.
I don't know a direct way to get gdb to run arbitrary commands when the program crashes. Here is one workaround I can think of:
Create and register a signal handlers for SIGSEGV.
Tell gdb not to stop on that signal (handle SIGSEGV nostop)
Set a breakpoint at the first line of your signal handler.
Assign commands to the breakpoint from step 3
Why not just run the process interactively in a persistent screen session? Why must it be a daemon when debugging? Or just run gdb in the screen session and attach it to the running process (e.g. gdb /path/to/binary -p PID_of_binary) after it forks.
First, I'd setup your shell / environment to give you a core dump. In bash:
ulimit -c unlimited
Once you have the core dump, you can use gdb to examine the stack trace:
gdb /path/to/app /path/to/core/file
I'm not really a gdb expert but two things come to mind
Tracepoints which might give you the necessary information as your program runs or
Use gdb's remote debugging facility to debug your program while it's running as a daemon.
How to generate a stacktrace when my gcc C++ app crashes answer for this question should do what you want. (assuming you can make changes in your code)
You might want to take a look at how Samba facilitates debugging; it has a configurable "panic action" that can suspend the application, notify the developer, spawn gdb, etc., and is run as part of its signal handler. See lib/util/fault.c in the Samba source tree.
My practice: comment out daemon function call, rebuild binary, then use gdb to run.