Today I encountered the following error out of valgrind:
Syscall param recvmsg(msg.msg_iov[0]) points to unaddressable byte(s)
I’ve had some variant of this a couple of times now. The first time it was a pseudo-false-positive: in resorting to culling code until the error went away I found it was replaced my a memory leak. After fixing the leak and putting all the culled code back, the board was green.
Today I had it in another situation. Take the following classes:
class A {
public:
A(shared_ptr<B> b) : b(b) {}
};
class B {
public:
virtual void foo() {}
};
class C : public B {
public:
virtual void foo() {}
};
The substantial change I made was to introduce an extra parameter into the signature of B::foo:
class B {
public:
virtual void foo(int arg) {}
};
But I forgot to update it in C. The error was supposedly happening when A was constructed, which made little sens because there were no changes to A that would affect the layout of an A instance. So, I tried progressively reverting changes until the function signature was the only change left, and then it dawned on me that the error was in a unit test so it might be something with the mock (in this case C). I updated the signatures in the mock, and the error went away. At this point I delve into hearsay: I can only conclude that the uninitialized bytes were to do with the v-table, and because I had a weird situation with effectively an overload on a subclass that didn’t exist on the superclass the v-table must have been a bit odd-looking to valgrind.
Anyhow, the point of this post is not to get into the nitty gritty, because I just don’t have that level of compiler-foo, rather to note that this particular valgrind error is often quite cryptic, and that one of the possible causes is subclasses not properly extending their parents.
guysherman.com 