Re: pkg/50995: sigsegv in recv()

[christos%zoulas.com@localhost (Christos Zoulas)]

On Mar 23,  5:10pm, prlw1%cam.ac.uk@localhost (prlw1%cam.ac.uk@localhost) wrote:
-- Subject: pkg/50995: sigsegv in recv()

| >Number:         50995
| >Category:       pkg
| >Synopsis:       sigsegv in recv()
| >Confidential:   no
| >Severity:       serious
| >Priority:       high
| >Responsible:    pkg-manager
| >State:          open
| >Class:          sw-bug
| >Submitter-Id:   net
| >Arrival-Date:   Wed Mar 23 17:10:00 +0000 2016
| >Originator:     Patrick Welche
| >Release:        NetBSD-7/amd64
| >Organization:
| >Environment:
| >Description:
| Running pkgsrc dansguardian 2.12.0.3nb4 on a busy NetBSD-7/amd64 (both
| original 7 kernel and most recent from 7 branch), dansguardian will run
| fine for say a fortnight, then run through a patch of coredumps as a
| result of a SIGSEGV. There is no apparent pattern. Could also coredump
| on startup.
| 
| NetBSD-5/i386 does not exhibit the problem.
| 
|   http://www.netbsd.org/~sborrill/dansguardian/
| 
| contains the patches that were added to dansguardian to try to see
| whether the issue was with the application or the recv() call.
| BaseSocket.cc is the patched source file. The syslog line is not
| reached. "dansguardian" is the 9.2M binary with symbols, dansguardian.core
| one of the 43M core files. core file says:
| 
| 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?

christos