I have an application, in C++ over running linux, which on exit gets abort signal.
Before I go after the code to hunt down the problem, I need to know what could be the cases in which I shall get an abort signal from kernel. This could give me proper direction to debug.
Please mention each and every potential scenario in which an application could get an abort signal.
# specifics of execution scenario are,
process is in exit mode, i.e exit() routine is called for graceful shutdown of process.
consequently all the global object destructors are called.
TIA
Compile it with -g
Run it from a debugger
When the application crashes, the debugger will give you the line, let you inspect thread, variables...
Other solution:
change your core dump generation with ulimit
load the core dump in gdb post mortem
Root cause can be multiple : reading outside of your memory space, division by 0, dereferencing invalid pointer...
I would try running under valgrind. There could be a memory error even before the abort and valgrind could notice that and tell you. If this is the case, you will find the error much easier than with a conventional debugger like gdb.
The cause for aborted is in general an assertion failure
for example
(gdb) bt
#0 0x00000035fbc30265 in raise () from /lib64/libc.so.6
#1 0x00000035fbc31d10 in abort () from /lib64/libc.so.6
#2 0x00000035fbc296e6 in __assert_fail () from /lib64/libc.so.6
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've been debugging multi-process job. Create multiple threads at program initialization. I found while I'm using gdb for debug, the threads can all be set up successfully, but when I execute the program directly in linux environment, it stucks after part of the threads being created. I'm thinking it must be some schedule problem between thread sleep and wakeup but haven't figure that out yet..
And although gdb can create the threads successfully, it quits with an unexpected segmentation fault in a glibc function after thread killed itself:
res_thread_freeres () at res_init.c:642
642 if (_res.nscount == 0)
which is also wierd because I can check the value of _res.nscount, it didn't overflow definately.
So.. Does anybody have a clue about the execution difference between an actual os and gdb debug environment? Thanks!
Update:
I've located the problem to pthread being set to SCHED_FIFO, after I removed this, it works fine. But I'm still not aware of why the program works fine in gdb environment.. Actually the thread state of the program got changed the moment it is attached to gdb.
Have been trying to remote debug an application running on my target using GDB.
The target is Armv6 based, the OS is linux and the application is a QT based Multithreaded application.
I am able to set the break point. But when the break point is hit, program gets crashed along with SIGTRAP.
Hint: I am able to run another small sample Multithreaded QT-App on the same target.
What could be the problem?
GDB Log as follows
Breakpoint 1 at 0x4ad52c: file <> , <>. (2 locations)
(gdb) c
Continuing.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.
(gdb)
(gdb)
You have maybe a solution here:
http://sourceware.org/gdb/wiki/FAQ#GDB_does_not_see_any_threads_besides_the_one_in_which_crash_occurred.3B_or_SIGTRAP_kills_my_program_when_I_set_a_breakpoint.
Hope this help.
Regards.
well, the gdb trace the process by ptrace , and the ptrace set breakpoint in the space of the
thread , the space addr is shared by the other thread, if the other thread reached the breakpoint, oh, the kernel generate a sigtrap for the thread.
more info in the follow
http://lists.alioth.debian.org/pipermail/ltrace-devel/2006-April/000036.html
I have an application that I am debugging and I'm trying to understand how gdb works and why I am not able to step through the application sometimes. The problem that I am experiencing is that gdb will hang and the process it is attached to will enter a defunct state when I am stepping through the program. After gdb hangs and I have to kill it to free the terminal (ctrl-C does not work, I have to do this from a different terminal window by getting the process id for that gdb session and using kill -9).
I'm guessing that gdb is hanging because it's waiting for the application to stop at the next instruction and somehow the application finished execution without gdb identifying this. But that's just speculation on my part from the behavior I've observed thus far. So my question is if anyone has seen this type of behavior before and/or could suggest what the cause might be. I think that might help me improve my debugging strategy.
In case it matters I'm using g++ 4.4.3, gdb 7.1, running on Ubuntu 10.04 x86_64.
I had a similar problem and solved it by sending a CONT signal to the process being debugged.
I'd say the debugged process wouldn't sit idle if it was the cause of the hang. Every time GDB has completed a step, it has to update any expressions you required to print. It may include following pointers and so, and in some case, it may fail there (although I don't remind of a real "hang"). It also typically try to update your stack trace. If the stack trace has been corrupted and is no longer coherent, it could be trapped into an endless loop. Attaching gdb to strace to see what kind of activity is going on during the hang could be a good way to go one step further into figuring out the problem.
(e.g. accessing sources through a no-longer-working NFS/SSHFS mount is one of the most frequent reason for gdb to hang, here :P)
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