| To: | Nathan Scott <nathans@xxxxxxxxxx>, Ken McDonell <kenj@xxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [pcp] errors from socket code on Mac OS X |
| From: | Dave Brolley <brolley@xxxxxxxxxx> |
| Date: | Wed, 06 Jul 2016 12:31:23 -0400 |
| Cc: | PCP <pcp@xxxxxxxxxxx> |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <2068385288.4119706.1467774342414.JavaMail.zimbra@xxxxxxxxxx> |
| References: | <577C1045.1040108@xxxxxxxxxxxxxxxx> <577C1D0A.6040300@xxxxxxxxxx> <2068385288.4119706.1467774342414.JavaMail.zimbra@xxxxxxxxxx> |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 |
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 |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | pmmgr.1: fix typo, Marko Myllynen |
|---|---|
| Next by Date: | Re: [pcp] pcp2influxdb - a clone of pcp2graphite, Alec Ten Harmsel |
| Previous by Thread: | Re: [pcp] errors from socket code on Mac OS X, Ken McDonell |
| Next by Thread: | Re: [pcp] errors from socket code on Mac OS X, Ken McDonell |
| Indexes: | [Date] [Thread] [Top] [All Lists] |