|
From: Ivan S. J. <isj...@i1...> - 2015-08-24 09:37:58
|
(x86, gcc, valgrind v3.10.0) I have a C program that infrequently coredumps due to jump to an invalid address. I have been running it with valgrind for the past 3 months trying to track down this error but the results have not been helpful in the 10 coredumps so far because there are no stack backtraces when that jump occurs ==20897== Jump to the invalid address stated on the next line ==20897== at 0x810CFFFF: ??? ==20897== Address 0x810cffff is not stack'd, malloc'd or (recently) free'd ==25919== Jump to the invalid address stated on the next line ==25919== at 0xBA0CFFFF: ??? ==25919== Address 0xba0cffff is not stack'd, malloc'd or (recently) free'd There are fine stack backtraces for the other errors (conditional jumps mostly). The program is compiled with gcc -m32 -O0 -ggdb and I have verified that the compiler correctly maintains the EBP register. The program uses a large 3rd-party library that uses callbacks a lot of places, so my hunch is that a memory overwrite destroys a function pointer and that causes the invalid jump. But I need the stack backtrace to at least narrow it down. Any suggestions? |
|
From: John R. <jr...@bi...> - 2015-08-29 17:41:22
|
> (x86, gcc, valgrind v3.10.0)
Thank you for stating that information about the environment!
[Sometimes the output from "gcc --version" and "/lib*/libc.so.N"
also matters, but not in this case.]
> ==20897== Jump to the invalid address stated on the next line
> ==20897== at 0x810CFFFF: ???
> ==20897== Address 0x810cffff is not stack'd, malloc'd or (recently) free'd
In general, run with --vgdb-error=0 which enables simultaneous gdb and memcheck.
(Hint: after the initial attach, then gdb is waiting for commands and "continue".)
Then you can plant gdb breakpoints and watch as execution proceeds,
in order to bound and narrow the scope of the problem.
Add a subroutine which turns on the hardware feature which records successful
branches ("branch trace buffer"). This requires a trek through documentation
about the specific CPU and the Linux 'perf' subsystem.
|