On 07/28/2014 09:12 PM, Nathan Scott wrote:
Hi Dave,
I happened to run a non-secure-sockets build through QA recently,
and noticed a handful of new failures there. They look related to
recent discovery and FNDELAY changes? .bad files attached.
Re: tests 531 and 533:
dbpmda was calling __pmConnectTo() even though it does not have code to
handle non-blocking I/O. In particular, it was not resetting the
original file control flags after connecting, as all other callers of
__pmConnectTo() are expected to (and do). It was therefore possible that
a subsequent read would return as incomplete with EAGAIN. This has
probably been broken for some time. The problem is fixed by using
__pmConnect() which does not set the FNDELAY flag.
Re: test 766:
The native version of __pmStringToSockAddr() calls inet_pton(3), which
does not handle the '%<interface>' extension for specifying the scope of
link-local ipv6 addresses. For example, fe80::3ea9:f4ff:fe76:6c24%em1.
The function has now been modified to extract the suffix and to set the
scope_id in the address manually.
The commits below have been pushed to the brolley/dev branch of pcpfans.
Dave
-------------------------------------------------
commit b8d4c72b5b821a5c624a220e210b900a93b73803
Author: Dave Brolley <brolley@xxxxxxxxxx>
Date: Wed Jul 30 14:43:26 2014 -0400
src/dbpmda/src/pmda.c: Use __pmConnect() instead of __pmConnectTo().
The surrounding code does not expect non-blocking I/O and so should
not call __pmConnectTo().
commit 1665f9ec83fd3ab2eeb0f1fb85b1cca0eb898cd3
Author: Dave Brolley <brolley@xxxxxxxxxx>
Date: Wed Jul 30 14:37:20 2014 -0400
Handle the '%<interface' for link-local ipv6 addresses in
__pmStringToSockAddr().
Native implementation only. The NSPR implementation already handles
this.
|