pcp
[Top] [All Lists]

Re: [pcp] URGENT potentially serious regression in 3.7.0

To: pcp@xxxxxxxxxxx
Subject: Re: [pcp] URGENT potentially serious regression in 3.7.0
From: Dave Brolley <brolley@xxxxxxxxxx>
Date: Tue, 02 Apr 2013 14:29:06 -0400
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <515A7236.5080901@xxxxxxxxxxxxxxxx>
References: <513B99E4.7030007@xxxxxxxxxxxxxxxx> <513D9A93.6080806@xxxxxxxxxxxxxxxx> <515A7236.5080901@xxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4
On 04/02/2013 01:52 AM, Ken McDonell wrote:
OK, I've spent many hours on this one and finally cracked it ... the core of 
the problem is this turdlet in the pmcd code ...

#if 0 /* TODO: IPv6 -- how to trace an ip address?? */
     pmcd_trace(TR_ADD_CLIENT, ClientIPAddr(&client[i]), fd, client[i].seq);
#else /* For now so that the output is not completely missing. */
     pmcd_trace(TR_ADD_CLIENT, 0, fd, client[i].seq);
#endif

Combine this with a call to gethostbyaddr() in pmcd's TR_ADD_CLIENT trace code (a 
fundamentally bad idea to be doing reverse DNS lookup at this point, but that is an 
earlier design error), and the gethostbyaddr() call always times out looking up the 
address "0", after about 5 seconds, ... and bingo you have basis for the qa/169 
failure.
My apologies for the turdlet(tm) and the subsequent fallout. There is another potentially unnecessary reverse lookup in __pmGetAddrInfo (both implementations call __pmGetNameInfo) that I'm looking into as well.

Dave

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