I'm debugging a program with Valgrind. I would like it to stop and core dump the program just after it detects the first error (so that I can examine more closely what's going on). Is this possible?
You can use gdb together with valgrind, to put breaks, step, next, and stop on errors.
Use --vgdb-error=0 and follow the instructions to connect gdb to Valgrind
Related
I am trying to write a simple OS, I already wrote a bootloader but now I want to debug it, so I switched from using VirtualBox to QEMU because I saw it had better debugging.
The problem is that after I added the -s parameter to QEMU command and successfully connected via GDB, it says that the symbol table isn't loaded and that I should use the "file" command.
The only difference from what I did to what I saw people on the Internet do, is that they started GDB with gdb vmlinux, but I can't do that because I am not debugging a Linux kernel... so I figured that the issue is that I didn't start GDB with an executable, but using the "file" command on my OS image, and the compiled and linked .out file, tells me it's a "DOS/MBR boot sector", so I can't start GDB with either of them (I tried to do that anyways, but GDB failed).
Help would be appreciated.
EDIT: also, I did assemble the bootloader with the -g and --gstabs+ options.
gdb would like a file so that it can give you symbolic debugging information. For that you will need to give it a file in a format with debug info which corresponds to where your OS ends up in RAM. The "DOS/MBR boot sector" file is a disk image (the BIOS will load part of this into RAM for you, and it will then presumably finish loading code itself).
But gdb will also entirely happily let you do assembly-level debugging; you can just ignore the warning about not having a symbol table, and use the single step instruction, disassemble-from-pc and similar commands:
"disas $pc,+32" disassembles 32 bytes from the current PC
the display command prints after execution stops, so "disp /3i $pc" will print the next 3 instructions every time gdb gets control
"stepi" and "nexti" do single-instruction step/next ("step" and "next" are source-line stepping and require debug info)
I implemented the program that uses mmap() system call, but Segmentation Fault occurs during process runtime.
So, I ran this program with gdb, but when I did it, it worked well without segment fault.
I wonder if it is possible that running with gdb can affect segment fault.
Could you tell me about it?
if it is possible that running with gdb can affect segment fault.
One possibility: GDB disables address randomization (so as to make reproducing the bug easier). You can re-enable it with:
(gdb) set disable-randomization off
GDB may also affect timing of threads, but you didn't mention threads, so that's less likely.
You are probably invoking Undefined Behavior somewhere in your code that is breaking C or C++ rules. Try to run the program under Valgrind. It should give you more information if this is the case.
I am testing a new driver on FreeBSD kernel.
This might be trivial for experienced developers, but I can't figure out the solution to this problem.
I have a kernel panic and when it panics, I get the backtrace of the panic.
The backtrace says that the panic occurred at say foo_bar() + 0x94. How can I extract the line no corresponding to foo_bar() + 0x94?
The kernel is built with debugging symbols. I have tried grepping nm kernel but it only contains debugging symbols.
What can I do to find the exact line no?
I suggest to read the FreeBSD Handbook on Kernel debugging
https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html
It has detailed explanation of how to create a core file and how to invoke the gdb.
Configure crashdumps - it's usually just adding 'dumpdev="AUTO"' to /etc/rc.conf and rebooting - and, after crash and subsequent reboot, analyze the dump with debugger, like this: "kgdb /boot/kernel/kernel /var/crash/vmcore.latest". The "kgdb" thing is basically GDB hacked up to support kernel debugging; the "where" command should show you the backtrace.
I am running in a very odd problem and I understand that it may be hard to diagnose from afar. But any hints would be helpful.
Having said this, here's my problem:
When I run valgrind to execute my program, an exception is thrown. However, when I call the program directly from the shell, it runs fine.
I have tried to use valgrind's vgdb to look into why this exception occurs. But this only allows me to investigate the variables after the exception occurred since I haven't found a good way to start gdb after I attached it to valgrind (without using continue) and step through the code.
I have already tried to recreate just the code segment where the exception is thrown but using the same variable content, I do not trigger the exception.
I should add that I'm doing this on a VMWare Workstation 8.0.1 virtual machine with with Ubuntu 11.10 and gcc 4.6.1, valgrind 3.7.0, gdb 7.3.
Any help is appreciated!
Just a few ideas:
a missing command line-parameter when you invoke your program via valgrind - maybe there's a special way to pass such parameter to your program
a different runtime behaviour of your program when it's executed in valgrind. valgrind is a kind of debugger, so maybe threads are scheduled in a different order and parts of your code might run slower. Maybe that triggers a bug like a race condition.
Is it possible to post some of the code here - especially around the location that exception is raised?
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