I have been debugging in GDB (C code). The issue is if I run my application and if it crashes, the control comes back to main()(app restarts). Hence will have no idea where it crashed. So I spend a lot of time stepping through each function.
I would like to know if there is anyway a log can be enabled which will generate the last line of execution before crash. This is just my assumption, if there is any other simpler way of doing this please let me know, this would save a great deal of time for me!
Also if the gdb generates a log where would the path be?
Thanks in advance.
This question is a little unclear to me, but I'll take a stab:
If you have GDB attached to the crashing process when it crashes, a crash should stop the program and put you back at the (gdb) prompt. If you then type bt, you should see the stack.
If you do NOT have GDB attached, then this answer to a related question might help. (In short, maybe you want the system to create a core dump when the program crashes. A core dump is just a file that contains a lot of information about the crashed process. You can use GDB with the core dump to see the stack.)
If you don't know, post what you see on the screen when this happens, and we'll guess.
In any case, the program definitely should not start over at main(). It seems worthwhile to track down why this happens and precisely what's going on. Does control really jump to main in the same process, as opposed to another process somehow being automatically started?
Run your program in gdb mode.
$ gdb ./myProgram
Set break point to expected location.
$ break functionName
Or set break point to particular line number.
$ break 15
Start the execution
$ r
Step into or step out the execution by 's' or 'n'
$ s
once the program crash, do 'bt' for backtrace.
$ bt
you can go up and down in your trace by 'up' & 'down' command
$ up
Can also take alternate way. Debug program with “core” as the core dump file.
$ gdb executableFilename core
$ bt
Related
I'm executing an arm elf (zephyr os + tfm) on qemu and make it run some tests.
Unfortunately, it stops at a certain point without either an error message or warnings.
I also tried with GDB, but at a certain point, it just stops.
It always stops at the same point for the same version (if I add some debug prints it stop earlier or later).
I think there is some pending interrupt that simply is not caught... no idea honestly.
Thus, my question: How to find out the cause of hanging software?
Or also, how can I check which interrupt has been risen to stop the normal execution?
For future reference TF-M has an option to enable an exception info dump print in case of faults. I would start enabling that by setting the following define in the cmake config step: -DTFM_EXCEPTION_INFO_DUMP=True
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 am quite new to the area of compilers. I'm using gcc and I want to get execution history of a program for a particular run i.e. only those statements which are actually executed in the last run.
Is it possible with gdb? I couldn't get relevant options in gdb which could output executed statements.
Or is there any other way of obtaining execution history?
Regards,
Nikhil.
Process Record May be what you're looking for. The link has a quick tutorial and an overview of the functionality.
From the linked wiki page:
Compile this program with -g, and load it into gdb, then do the
following:
(gdb) break main
(gdb) run
(gdb) record
This will turn on process recording, which will now record all subsequent instructions executed by the program being debugged.
Note that you can start process recording at any point (not just at
main). You may choose to start it later, or even earlier. The only
restriction is that your program has to be running (so you have to
type "run" before "record"). If you want to start recording from the
very first instruction of your program, you can do it like this:
(gdb) break _start
(gdb) run
(gdb) record
Hope this helps.
You can use set history save command to start recording history. This can be written into the ~/.gdbinit file. Look at the docs for more information.
I would like to synthesise a native code fault. This is so that we can see where in particular some debugging output gets put when that occurrs.
Pskill (from Sys-Internals) causes a graceful exit. DotCrash.exe doesn't seem to be available anymore from Microsoft directly.
Is there any way to externally cause a crash in a process?
I've done this before using windbg by:
Starting the process
Attaching to the process with windbg
Setting a breakpoint on one of my app's functions
Running the app until I hit the breakpoint
In windbg setting a local variable to something that will cause an Access Violation (e.g. set a pointer to 0xFFFFFFFF or muck with the register values)
hit f5 and the app should hopefully crash
If what you want is the equivalent of a coredump, drwtsn32 -p ProcessId generates a dump of the current state of a running process. If you have the appropriate debug symbols you can get valuable information.
HTH.
As Nick mentions, this can easily be done via Debugging Tools for Windows - I'd go one step further though, and use cdb (the command-line WinDbg) to script the whole interaction.
If you need dumps at any desired time, you can use Microsoft's free debug diagnostic tool which has a nice UI to do that or on command line drwtsn32 -p processid as recommended by jrbjazz.
You could try using CreateRemoteThread. Using it correctly isn't easy, but making the other process crash should be pretty easy ;-)
Could you install some kind of hook function, or use something like the detours library?
I have big system that make my system crash hard. When I boot up, I don't even have
a coredump. If I log every line that
get executed until my system goes down. I will find that evil code.
Can I log every source code line in GDB to a file?
UPDATE:
ok, I found the bug. It was nasty. The application I started did not
take the system down. After learning about coredump inspection with mdb, and some gdb stepping I found out that the systemcall causing the dump, was not implemented. Updating the system to latest kernel will fix my problem. Thanks to all of you.
MY LESSON:
make sure you know what process causes the coredump. It's not always the one you started.
Sounds like a tricky little problem.
I often try to eliminate as many possible suspects as I can by commenting out large chunks of code, configuring the system to not run certain pieces (if it allows you to do that) etc. This amounts to doing an ad-hoc binary search on the problem, and is a surprisingly effective way of zooming in on offending code relatively quickly.
A potential problem with logging is that the log might not hit the disk before the system locks up - if you don't get a core dump, you might not get the log.
Speaking of core dumps, make sure you don't have a limit on your core dump size (man ulimit.)
You could try to obtain a list of all the functions in your code using objdump, process it a little bit and create a bunch of GDB trace statements on those functions - basically creating a GDB script automatically. If that turns out to be overkill, then a binary search on the code using tracepoints can also help you zoom in on the problem.
And don't panic. You're smarter than the bug - you'll find it.
You can not reasonably track every line of your source using GDB (too slow). Besides, a system crash is most likely a result of a system call, and libc is probably doing the system call on your behalf. Even if you find the line of the application that caused OS crash, you still don't really know anything.
You should start by clarifying which OS is crashing. For Linux, you can try the following approaches:
strace -fo trace.out /path/to/app
After reboot, trace.out will contain syscalls the application was doing just before the crash. If you are lucky, you'll see the last syscall-of-death, but I wouldn't count on it.
Alternatively, try to reproduce the crash on the user-mode Linux, or on kernel with KGDB compiled in.
These will tell you where the problem in the kernel is. Finding the matching system call in your application will likely be trivial.
Please clarify your problem: What part of the system is crashing?
Is it an application?
If so, which application? Is this an application which you have written yourself? Is this an application you have obtained from elsewhere? Can you obtain a clean interrupt if you use a debugger? Can you obtain a backtrace showing which functions are calling the section of code which crashes?
Is it a new hardware driver?
Is it based on an older driver? If so, what has changed? Is it based on a manufacturer's data sheet? Is that data sheet the latest and most correct?
Is it somewhere in the kernel? Which kernel?
What is the OS? I assume it is linux, seeing that you are using the GNU debugger. But of course, that is not necessarily so.
You say you have no coredump. Have you enabled coredumps on your machine? Most systems these days do not have coredumps enabled by default.
Regarding logging GDB output, you may have some success, but it depends where the problem is whether or not you will have the right output logged before the system crashes. There is plenty of delay in writing to disk. You may not catch it in time.
I'm not familiar with the gdb way of doing this, but with windbg the way to go is to have a debugger attached to the kernel and control the debugger remotely over a serial cable (or firewire) from a second debugger. I'm pretty sure gdb has similar capabilities, I could quickly find some hints here: http://www.digipedia.pl/man/gdb.4.html