pcp
[Top] [All Lists]

Re: [pcp] errors from socket code on Mac OS X

To: Dave Brolley <brolley@xxxxxxxxxx>, Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] errors from socket code on Mac OS X
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Thu, 7 Jul 2016 10:47:23 +1000
Cc: PCP <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <577D325B.6060208@xxxxxxxxxx>
References: <577C1045.1040108@xxxxxxxxxxxxxxxx> <577C1D0A.6040300@xxxxxxxxxx> <2068385288.4119706.1467774342414.JavaMail.zimbra@xxxxxxxxxx> <577D325B.6060208@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
On 07/07/16 02:31, Dave Brolley wrote:
On 07/05/2016 11:05 PM, Nathan Scott wrote:
... and it looks like we are seeing a sockaddr that is (still) completely
zeroed after we accept on the fd in pmcd/client.c AcceptNewClient.  The
attached patch seems to tidy it up for me ... whaddya think Dave?  Are we
likely to see other places where this happens, I wonder?

I would think that it could happen for any call to __pmAccept().

In your patch, based on  __pmCheckAcceptedAddress() requiring that the
family be set in the address, you set it before calling __pmAccept(). If
we're going to require that the family be provided to
__pmCheckAcceptedAddress() via __pmAccept(), then we should probably
bite the bullet and enforce that by making the family a 4th parameter to
__pmAccept() and have __pmAccept set it, when needed.

Dave


I don't think the change needs to be that intrusive. I have a simpler approach that I've committed in my tree (patch attached).

This addresses the Mac OS X issues and passes all the -g pmcd QA tests on both Mac OS X and Ubuntu 16.04 and now has good air time on a handful of other QA hosts.

Attachment: pmaccept.patch
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>