|
From: Mathieu L. <mat...@gm...> - 2010-10-07 11:09:32
|
hi, While valgrinding a program of mine, I get this warning: ==4350== Thread 2: ==4350== Invalid read of size 8 ==4350== at 0x5F5D092: ns3::StackTrampoline::SignalHandler(int) (pthread-fiber-manager.cc:168) ==4350== by 0x37FB40F0EF: ??? (in /lib64/libpthread-2.11.2.so) ==4350== by 0x37FB40EFBA: raise (pt-raise.c:42) ==4350== Address 0x67494f0 is on thread 2's stack which corresponds to the following assembly code: 0x0000000005f5d092 <ns3::StackTrampoline::SignalHandler(int)+50>: mov -0x8(%rbp),%rax 0x0000000005f5d096 <ns3::StackTrampoline::SignalHandler(int)+54>: mov 0xd0(%rax),%rax with the program counter being (gdb) p $pc $2 = (void (*)(void)) 0x5f5d092 <ns3::StackTrampoline::SignalHandler(int)+50> and the frame pointer: (gdb) p $rbp $3 = (void *) 0x67494f8 So, yes, this code is accessing a variable located on the stack. But, what is wrong with that ? The stack page is allocated with mmap, it is set with sigaltstack and registered with VALGRIND_STACK_REGISTER What could I have done wrong to trigger this warning ? Mathieu -- Mathieu Lacage <mat...@gm...> |
|
From: John R. <jr...@bi...> - 2010-10-07 14:22:09
|
> ==4350== Invalid read of size 8 > ==4350== at 0x5F5D092: ns3::StackTrampoline::SignalHandler(int) > (pthread-fiber-manager.cc:168) > which corresponds to the following assembly code: > 0x0000000005f5d092 <ns3::StackTrampoline::SignalHandler(int)+50>: mov > -0x8(%rbp),%rax > 0x0000000005f5d096 <ns3::StackTrampoline::SignalHandler(int)+54>: mov > 0xd0(%rax),%rax > > with the program counter being > (gdb) p $pc > $2 = (void (*)(void)) 0x5f5d092 <ns3::StackTrampoline::SignalHandler(int)+50> > and the frame pointer: > (gdb) p $rbp > $3 = (void *) 0x67494f8 > > So, yes, this code is accessing a variable located on the stack. But, > what is wrong with that ? Well, what is the value of the stack pointer %rsp [print $sp in your gdb] and does that correspond to valgrind's current idea of the stack pointer? It seems that ns3::StackTrampoline::SignalHandler might be the signal handler, so execution would be very soon after the kernel had switched the stack pointer, and valgrind might not have noticed yet. valgrind has a history of lagging in this area. -- |
|
From: Mathieu L. <mat...@gm...> - 2010-10-11 09:27:30
|
On Thu, Oct 7, 2010 at 16:21, John Reiser <jr...@bi...> wrote: > Well, what is the value of the stack pointer %rsp [print $sp in your gdb] > and does that correspond to valgrind's current idea of the stack pointer? > It seems that ns3::StackTrampoline::SignalHandler might be the signal > handler, so execution would be very soon after the kernel had switched > the stack pointer, and valgrind might not have noticed yet. valgrind > has a history of lagging in this area. I am playing some fairly nasty tricks with the stack in my code so I had to convince valgrind that I am right with VALGRIND_MAKE_MEM_DEFINED. Mathieu -- Mathieu Lacage <mat...@gm...> |