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?
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
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
my program is using libhdfs.so for hdfs read/write, I want to set a break point for debugging, but when this program runs to the point of hdfsConnect, it exits with a segmentation fault.
interesting thing is that when I run the program normally, segmentation fault does't happen at all.
what is likely the root cause? is there some runtime environment I should setup when debugging libhdfs.so?
it turns out to be a JNI problem anther than a libhdfs.so specific problem, the solution can be found here:
Strange sigsegv while calling java code from c++ through jni
what is likely the root cause?
The likely root cause is a bug in your program, which manifests itself as a crash under GDB, but remains hidden when run outside of GDB.
This makes the problem easier to debug: the opposite (crashes outside of GDB, works under GDB) is often harder.
Your first step should be to run the program under Valgrind and make sure it's clean.
There is unix-socket server written on PHP (but I don't think it has something to with it). Client side is written on c++ and based on boost::asio library. When I launch program normally - everything works fine, except one (not related to socket communication) bug that I obviously want to debug. But when I start step-by-step debugging it I immediately receive 'Broken Pipe' error on the steps which perform write operations on sockets. If breakpoint is set up after socket write operation - everything work fine until the next attempt to step over the write func.
Spent whole day trying to solve this problem, but unsuccessfully...
Had anyone met the same trouble?
using GDB bundled with xCode 3.2.5 (64-bit) under OS X 10.6.7
GDB uses signals aggressively. If you want to install signal handlers, check out the following example:
https://github.com/sean-/Boost.Examples/blob/master/asio/timer/timer.cc#L106
I have a timing bug in my application which only occurs when I use valgrind, because valgrind slows down the process so much.
(it's actually a boost::weak_ptr-exception that I cannot localize)
Now I wonder how to reproduce the bug with gdb. I don't see a way to combine gdb + valgrind.
Thanks.
You can start gdb when an error is detected by valgrind (--db-attach=yes). Even if the exception doesn't trigger a memory error at the moment, it's easy to fake a bad memory access in that path.