|
From: <led...@vt...> - 2007-01-15 15:52:13
|
I am running a program on RH linux on a ppc970 (ppc64). I have a couple of different applications that use a third party library. running valgrind on any of these applications results in a Seg Fault. The seg fault happens shortly after an Invalid read error. I have run the applications on their own and using gdb and there is no seg fault. After the Invalid read error, there is a Process terminating with default action of signal 11 (SIGSEGV) error and not only does the program die, but valgrind appears to Seg fault as well. I recompiled my code without compiler optimizations, and I get a stack trace, but deepest frame in the stack cannot be correct. The deepest frame (call it A) is not a function that is called by the previous frame (Call it B). The valgrind stack trace shows a valid stack trace until the deepest frame. The valgrind stack trace is something like: ==29166== at 0x10061770: (within myApp) ==29166== by 0x100B4AF0: suspiciousFunction (myfile1.c:929) ==29166== by 0x1001B2A0: CallingFunction (myfile2.c:187) ==29166== by 0x1001AF28: HigherCallingFunction (myfile3.c:294) ... When valgrind falls into gdb, I do a bt and get: (gdb) bt #0 0x10061770 in vedor_private_function () #1 0x10033fd0 in vendor_public_function () #2 0x100b4af4 in suspiciousFunction (mutex=0x6d616a6f) at myfile1.c:929 Previous frame inner to this frame (corrupt stack?) In reality, CallingFunction calls vendor_public_function, not suspiciousFunction, but suspiciousFunction ends up at the end of the valgrind stack trace and at the start of the gdb stack trace. The vendor code is a highly optimized library. I'm not sure how it was compiled. I'm not sure why the program seg faults under valgrind and not under gdb or by itself. I would say that the Invalid read could be causing it, but looking at the stack traces and the actual code, there isn't any invalid read. Also, should valgrind itself be seg faulting if the program seg faults? Thanks for your time. -Cass The actual function call |