I have a server program, which doesn't have a very clean/graceful shutdown (not supposed to terminate in general). When tracing memory leaks, I run it under valgrind, but finally have to kill the process by a signal (^C). Generally I try to terminate the process when the ambiance is quiet but still then some threads might have been busy processing jobs and memory held by them cause false alarms. To assist such analysis, is there any way (tool) in valgrind, so that it can print the backtrace of threads when the program exits (by a signal?).
I know it's inconvenient, but could you get your program to dump core when it gets this signal, then diagnose the core dump with gdb?
Don't sure I quite understand your question, but you can print backtrace of all pthreads by gdb:
thread apply all bt
Related
I have the task to debug a program using Valgrind. The program becomes very slow due to the Valgrind usage. This is a problem, because the program has a watcher thread that kills slow threads with SIGABRT if they spend too much time in certain functions. The program is in a valid state when it exits in that way, so I would like to keep it running even if SIGABRT is cast. I cannot change the program to switch off the watcher thread from the source code.
Now my question:
Does Valgrind, or a tool compatible with Valgrind, give me the option to say to the program: "If you receive SIGABRT, treat it as a null op and go on?"
You might achieve what you want by running your program under valgrind + gdb, using vgdb.
With gdb, you can then control what to do with the SIGABRT signal.
For example, launch your program with:
valgrind --vgdb-stop-at=startup your_program
In another window, launch gdb:
(gdb) handle SIGABRT nostop print nopass
(gdb) target remote | vgdb
(gdb) continue
See http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver for more information.
I am running a Linux program that uses a lot of memory. If I terminate it manually using Ctrl-C, it will do the necessary memory clean-up. Now I'm trying to terminate the program using a script. What is an elegant way to do so? I'm hoping to do something similar to Ctrl-C so it can do the memory clean-up. Will using the "kill -9" command do this?
What do you mean by memory clean-up?
Keep in mind that memory will be freed anyway, regardless of the killing signal.
Default kill signal - SIGTERM (15) gives application a chance to do some additional work but it has to be implemented with a signal handler.
Signal handling in c++
I am debugging a core file that was generated in a multi-threaded environment. The process crashed after it received a SIGABRT. The crash seems to be bit tricky and I want to know the execution state of all the threads when the crash happened. I guess the simple backtrace command just gives the execution state of the thread that was running during the crash. I want to know what command I need to use to get the backtrace for all threads
May be you are looking for thread apply all bt?
i am getting crash in the thread. while debugging coredump with gdb, i want to see the state of the thread just before crash.
in my program i am raising a signal for that thread and handling it. it would be helpful to know the state before the thread has crashed and the time before the signal raised for that thread. is it possible to obtain this information from gdb?
Thanks
With "Reversible Debugging" of gdb 7.4 it is possible. Look here for a little tutorial.
Please refer to this page
http://linux-hacks.blogspot.com/2009/07/looking-at-thread-state-inside-gdb.html
If you have a multithreaded program (Linux 2.26 kernel), and one thread does something that causes a segfault, will the other threads still be scheduled to run? How are the other threads terminated? Can someone explain the process shutdown procedure with regard to multithreaded programs?
When a fatal signal is delivered to a thread, either the do_coredump() or the do_group_exit() function is called. do_group_exit() sets the thread group exit code and then signals all the other threads in the thread group to exit with zap_other_threads(), before exiting the current thread. (do_coredump() calls coredump_wait() which similarly calls zap_threads()).
zap_other_threads() posts a SIGKILL for every other thread in the thread group and wakes it up with signal_wake_up(). signal_wake_up() calls kick_process(), which will boot the thread into kernel mode so that it can recieve the signal, using an IPI1 if necessary (eg. if it's executing on another CPU).
1. Inter-Processor Interrupt
Will the other thread still be scheduled to run?
No. The SEGV is a process-level issue. Unless you've handled the SEGV (which is almost always a bad idea) your whole process will exit, and all threads with it.
I suspect that the other threads aren't handled very nicely. If the handler calls exit() or _exit() thread cleanup handlers won't get called. This may be a good thing if your program is severely corrupted, it's going to be hard to trust much of anything after a seg fault.
One note from the signal man page:
According to POSIX, the behaviour of a process is undefined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by the kill(2) or the raise(3) functions.
After a segfault you really don't want to be doing anything other than getting the heck out of that program.