pcp
[Top] [All Lists]

Re: Some recent QA regressions

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: Some recent QA regressions
From: Dave Brolley <brolley@xxxxxxxxxx>
Date: Fri, 11 Jul 2014 12:44:39 -0400
Cc: PCP Mailing List <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <2129401188.6256039.1404891527704.JavaMail.zimbra@xxxxxxxxxx>
References: <2129401188.6256039.1404891527704.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
On 07/09/2014 03:38 AM, Nathan Scott wrote:
Hi mate,

I've pulled all your current work, but had some problems with a
few tests (see attached bad files).  I found reverting the commit
below got us back into a healthy state, so pushed this for now -
when you figure it out, just "git revert" on my revert should do
a revert revert & then just apply your followup fix on top).

I don't think I have permission to do reverts on the dev branch of the SGI repository, and I would be too afraid to mess it up anyway, so I just redid the change in my pcpfans brolley/dev branch. That in addition to the fix which was to add EINPROGRESS handling to a few callers of __pmConnect().

Dave

----------------------------------

commit a705d6bb86d87fa0cdf0fb0accf5299212cef08d
Author: Dave Brolley <brolley@xxxxxxxxxx>
Date:   Fri Jul 11 12:35:56 2014 -0400

    Re-instate "Respect FNDELAY in __pmConnect() for secure connections."

    This re-instates commit 75e40a1a033df79ca36b4034670bede4ba39ebdf
    which was breaking tests 067, 110 and 156.

    commit ff23f3d6ab3d5d82141761722afec591f15a4597 adds the required
    error handling code to callers of __pmConnect.

commit ff23f3d6ab3d5d82141761722afec591f15a4597
Author: Dave Brolley <brolley@xxxxxxxxxx>
Date:   Fri Jul 11 11:25:40 2014 -0400

    Always handle EINPROGRESS from __pmConnect().

    NSPR sockets appear to always have the FNDELAY flag set, so it
    has always been possible for __pmConnect() to return -1 with
    neterror() set to EINPROGRESS. Now that the NSPR implementation of
    __pmConnect() uses PR_INTERVAL_NO_WAIT, this happens more often and
    a few callers that did not handle this were exposed.

    All callers of __pmConnect() now handle this situation.



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