Re: pkg/50995: sigsegv in recv()

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

On Wed, Mar 23, 2016 at 01:31:49PM -0400, Christos Zoulas wrote:
> | Program terminated with signal SIGSEGV, Segmentation fault.
> | #0  BaseSocket::readFromSocket (this=0x7f7f00000001, 
> |     this@entry=0x7f7fffffd320, buff=buff@entry=0x7f7fffffd25e "", 
> |     len=len@entry=1, flags=flags@entry=0, timeout=timeout@entry=360, 
> |     check_first=check_first@entry=true, 
> |     honour_reloadconfig=honour_reloadconfig@entry=true) at BaseSocket.cpp:476
> | 
> | 476                     rc = recv(sck, buff, cnt, flags);
> | 
> | Conjecture: another manifestation of the recvfrom returns EAGAIN loop problem.
> | >How-To-Repeat:
> 
> Well, in this case, this=0x7f7f00000001 does not seem right; for one, it should
> be aligned. Now you are asking this->sck as the first argument of the recv()
> call, and 
>  22175      1 dansguardian PSIG  SIGSEGV SIG_DFL: code=SEGV_MAPERR, addr=0x7f7f00000011, trap=6)
> 
> Which looks like it dereferencing it and dying before it gets a chance to call
> recv(). I wonder what's corrupting memory. The socket is coming from the stack
> so the address of "this" should look a lot like the others, but it looks like
> it lost it's bottom 32 bits... Perhaps something overwrote that word on the
> stack with a 0?

In terms of the code (class UDSocket : public BaseSocket):

bool getsock_fromparent(UDSocket &fd)
{
...
        rc = fd.readFromSocket(&buf, 1, 0, 360, true, true);

and here, fd.sck = 256 at address
(gdb) print &fd
$6 = (UDSocket *) 0x7f7fffffd320
(gdb) print &fd.sck
$4 = (int *) 0x7f7fffffd330

so how

(gdb) print this
$7 = (BaseSocket * const) 0x7f7f00000001

isn't == 0x7f7fffffd320, I don't know...