How to Drill Down on Apparent Corruption - c++

Question

I've been working with C and C++ for a fairly long time. I have a computer science minor. I'm familiar with the pitfalls intrinsic to the low level access to process memory these languages provide. I've spent days and weeks in them.
Learning to use valgrind about a decade ago was a lifesaver in terms of catching minor access errors and such. Currently, I also use ASAN with clion, and mistakes of this sort are usually caught and dealt with quickly.
I presume there's no bulletproof, however, and a recent problem has me completely stumped.1
I have an object that includes a non-public sockaddr_storage field named from. This can be accessed via:
const sockaddr_storage* getSockAddr () {
return &from;
}
But the address returned is wrong. Starting from a breakpoint on the return line in gdb:
Breakpoint 3, socketeering::Socket::getSockAddr (this=0x617000000400) at Socket.hpp:81
81 return &from;
(gdb) p this
$1 = (socketeering::UDPsocket * const) 0x617000000400
(gdb) p &from
$2 = (sockaddr_storage *) 0x617000000600
(gdb) p (const sockaddr_storage*)&from
$3 = (const sockaddr_storage *) 0x617000000600
Seems pretty clear the value returned has to be 0x617000000600. But no:
(gdb) fin
Run till exit from #0 socketeering::Socket::getSockAddr (this=0x617000000400) at Socket.hpp:81
0x00000000004290ab in udpHandler::dataReady (this=0x631000014810, iod=0x617000000400, con=0x60e0000249b0) at /opt/cogware/C++/Socketeering2/demo/echo_server.cpp:66
66 auto sa = sock->getSockAddr();
Value returned is $4 = (const sockaddr_storage *) 0x617000000618
^^
(gdb) p sock
$5 = (socketeering::UDPsocket *) 0x617000000400
That's no good -- it is 18 bytes inside the structure. Even worse, I CANNOT reproduce it with a simple SSCCE:
class foo {
sockaddr_storage ss;
public:
foo () { cout << &ss << "\n"; }
const sockaddr_storage* getSockAddr () { return &ss; }
};
Meaning it's not some misunderstanding of the rules, etc. It's obviously not a logic error either.
It has to be corruption, right?
This is a single threaded process, and if instead of fin I just keep stepping to see what's happening, there is literally nothing to see. One step to the function close, and the next one is at the assignment with the wrong value. Neither valgrind nor ASAN indicate any hijinx.
What can I look at to find out what is happening? Obviously something is going wrong here in between:
return &from;
And the actual return of a value. Is looking at assembly dumps for clues the only route left to me (presuming that would help at all, I'm no ASM guy)?
The answer I dread is there's nothing beyond scouring the code for mistakes that valgrind and ASAN didn't catch. Finding out under what circumstances they would not catch corruption is a starting place for that.
Which I did raise earlier in a now deleted question. All any one could say was exactly what I would say if I read a question like that: We need an SSCCE, and the corruption could be in other parts of the code. Point being, there's nothing in the information I have to show which explains the problem, but, sans inviting everyone onto a 10-20K LOC project, that's all I can do. So what I am asking now is not what's wrong, but "How can I determine what's wrong?"

Answer 1

Is looking at assembly dumps for clues the only route left to me
Yes, using a disas command is the appropriate approach here.
(presuming that would help at all, I'm no ASM guy)?
Even if you can't write assembly, it's often pretty easy to read assembly. Especially if it's something like x86_64 and doesn't involve complicated bit twiddling or floating point. And it's a skill that will serve you well.
Usually the problem of this sort is a result of an ODR violation: somewhere in your program you have a different definition of socketeering::Socket, one in which the offset between this and from is 24 (it's not 18 bytes, it's 0x18 bytes!) instead of 0.
Often such ODR violation comes from using different #defines in different parts of the code, e.g.
class Socket {
#if defined(TRACING_ON)
char trace_buf[24];
#endif
sockaddr_storage from;
};
Compile above struct in one .cc file with -DTRACING_ON, compile another .cc without it, link them together into a single binary and BOOM: you may see exactly the bug you've described.
Sometimes, the problem comes from not recompiling all code (e.g. you may have an old object or a shared library laying around).
It could also come from linking together code built by different compilers, though this is rare (usually if the compilers are not ABI-compatible, they use different name mangling to preclude the program from linking).
Note: if Socket inherits from some other class, the difference may be coming from the superclass and not the Socket itself.