> ==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. -- ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
