Site Navigation

Date:      Wed, 8 Jun 2016 15:32:17 -0400
From:      "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com>
To:        jenkins-admin@freebsd.org
Cc:        Garrett Cooper <ngie@FreeBSD.org>, freebsd-stable@FreeBSD.org
Subject:   Re: FreeBSD_stable_9 - Build #1142 - Failure
Message-ID:  <86360996-66C7-402B-90F6-E90F66F5C3EA@gmail.com>
In-Reply-To: <1817953327.48.1465413518451.JavaMail.jenkins@jenkins-9.freebsd.org>
References:  <1817953327.48.1465413518451.JavaMail.jenkins@jenkins-9.freebsd.org>

---

next in thread | previous in thread | raw e-mail | index | archive | help

---

--Apple-Mail=_9BDA0B6D-93F0-4FFA-A738-464F3DB72F68
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jun 8, 2016, at 15:18, jenkins-admin@freebsd.org wrote:
>=20
> FreeBSD_stable_9 - Build #1142 - Failure:
>=20
> Build information: =
https://jenkins.FreeBSD.org/job/FreeBSD_stable_9/1142/
> Full change log: =
https://jenkins.FreeBSD.org/job/FreeBSD_stable_9/1142/changes
> Full build log: =
https://jenkins.FreeBSD.org/job/FreeBSD_stable_9/1142/console
>=20
> Change summaries:
>=20
> 301688 by ngie:
> MFstable/10 r301687:
>=20
> MFC r300624:
>=20
> Fix up r300385
>=20
> I accidentally glossed over the fact that tmp is manipulated via =
strchr, so
> if we tried to free `tmp` after r300385, it would have crashed.
>=20
> Create a separate pointer (tmp2) to track the original allocation of =
`tmp`,
> and free `tmp2` if `p->nc_lookups` can't be malloced
>=20
> CID: 1356026
>=20
> 301686 by ngie:
> MFstable/10 r301684:
>=20
> MFC r300385:
>=20
> Don't leak `tmp` if `p->nc_lookups` can't be malloced
>=20
> 301685 by ngie:
> MFstable/10 r301682:
>=20
> MFC r300386:
>=20
> Don't leak `handle` if svc_tp_create(..) succeeds and allocating a new
> struct xlist object fails
>=20
> CID: 978277
>=20
> 301681 by ngie:
> MFstable/10 r301680:
>=20
> MFC r300625:
>=20
> Remove unnecessary memset(.., 0, ..)'s
>=20
> The mem_alloc macro calls calloc (userspace) / malloc(.., =
M_WAITOK|M_ZERO)
> under the covers, so zeroing out memory is already handled by the =
underlying
> calls
>=20
> 301676 by ngie:
> MFstable/10 r301675:
>=20
> MFC r300714:
>=20
> The readme provides a high-level overview of how to upgrade top(1).
>=20
> Reviewed By: ngie
>=20
> 301674 by ngie:
> MFstable/10 r301673:
>=20
> MFC r299699:
>=20
> Remove NO_WERROR from libbsnmp/Makefile.inc
>=20
> This has been compiling without warnings with clang/gcc for a while =
now
>=20
> Tested with: clang 3.8.0, gcc 4.2.x, gcc 5.x
>=20
> 301672 by ngie:
> MFstable/10 r301671:
>=20
> MFC r299815:
>=20
> Remove NO_WERROR.clang from this Makefile
>=20
> This compiles with clang without warnings
>=20
> 301670 by ngie:
> MFstable/10 r301669:
>=20
> MFC r299806:
>=20
> Bump WARNS to 6
>=20
> 301668 by ngie:
> MFstable/10 r301667:
>=20
> MFC r299834:
>=20
> Fix .Dd
>=20
> Today is the 14th, not the 10th of May
>=20
> 301664 by ngie:
> MFstable/10 r301663:
>=20
> MFC r294507,r294567,r299466:
>=20
> r294507 (by harti):
>=20
> Fill the ifAlias leaf of the ifXTable with the interface description
> if there is one available and it fits into the maximum size (64 =
characters).
>=20
> r294567 (by bz):
>=20
> Change the variable to a #define in order to make gcc happy which
> otherwise will complain about "variably modified 'alias' at file =
scope".
> Unbreaks the build on gcc platforms.
>=20
> r299466 (by cem):
>=20
> bsnmpd: Fix size of trapsink::comm to match other community arrays
>=20
> This fixes a number of possible strcpy() buffer overruns between the =
various
> community strings in trap.c.
>=20
> CIDs:		1006820, 1006821, 1006822
>=20
> 301662 by ngie:
> MFstable/10 r301661:
>=20
> MFC r256678,r256680,r260986,r272878,r286402:
>=20
> r256678 (by syrinx):
>=20
> Fix SNMP Error response PDUs and properly encode them when using v3 =
auth/encryption.
>=20
> r256680 (by syrinx):
>=20
> Fix the -Wconversion warnings produced when compiling the SNMP agent.
>=20
> r260986 (by harti):
>=20
> Fix a problem with OBJECT IDENTIFIER encoding: need to check the
> second subid to be less than 40, not the first when the first
> subid is 0 or 1.
>=20
> r272878 (by syrinx):
>=20
> Fix a bug in decoding string indexes in snmp_target(3), thus causing
> bsnmpd(1) to not send v3 notifications properly; while here add two
> missing return statements which could lead to abort() in case of a
> rollback
>=20
> r286402 (by araujo):
>=20
> Fix variable 'old' is used uninitialized whenever '&&' condition is =
false.
> Spotted by clang.
>=20
> 301659 by ngie:
> MFstable/10 r301657:
>=20
> MFC r299701:
>=20
> Move _bsnmptools_debug extern from bsnmpmap.c to bsnmptools.h
>=20
> It was used in bsnmpmap.c but was stored in bsnmptools.c; moving the =
extern
> to the header allows us to cover all of our bases for the variable, =
and allows
> _bsnmptools_debug to be used in the future elsewhere -- not just =
bsnmpmap.c.
>=20
> 301654 by ngie:
> MFstable/10 r301653:
>=20
> MFC r299810:
>=20
> Correct function names that failed in error messages
>=20
> It should be calloc/strdup, not malloc
>=20
> 301652 by ngie:
> MFstable/10 r300475:
>=20
> MFC r299710,r299711,r299763,r299783,r299811:
>=20
> r299710:
>=20
> Staticize global variables only used in bsnmpimport.c to fix
> -Wmissing-variable-declarations warnings
>=20
> r299711:
>=20
> Fold two malloc + memset(.., 0, ..) calls into equivalent calloc calls
>=20
> r299763:
>=20
> Mute -Wstrlcpy-strlcat-size warning by using nitems with the size of =
the buffer
>=20
> This is a no-op as the malloc above set the size of the buffer to the =
size used
> below, but this keeps things consistent in case the malloc call =
changes somehow.
>=20
> r299783:
>=20
> Convert tok from enum tok to int32_t in function calls
>=20
> get_token(..) returns int32_t, not enum tok, and in many cases tests =
for items
> not in enum tok (e.g. '('). Make the typing consistent with get_token, =
which
> includes a domino effect of changing enum tok to int32_t.
>=20
> r299811:
>=20
> Use strdup instead of malloc + strlcpy
>=20
> Fix error messages on failure for calloc/strdup
>=20
> 301650 by ngie:
> MFstable/10 r301636:
>=20
> MFC r300867,r300932,r300934,r300941,r300972,r300973:
>=20
> r300867:
>=20
> Only expose `hint_uaddr` in the ND_DEBUG case
>=20
> This fixes a -Wunused-but-set-variable warning with gcc
>=20
> r300932:
>=20
> Catch malloc(3) errors and socket(2) errors
>=20
> - malloc failing will result in a delayed segfault
> - socket failing will result in delayed failures with setsockopt
>=20
> Exit in the event that either of these high-level conditions are met.
>=20
> CID: 976288, 976321, 976858
>=20
> r300934:
>=20
> Plug leak with ifp by calling freeifaddrs after calling getifaddrs
>=20
> Obtained from: NetBSD v1.18
>=20
> r300941:
>=20
> Don't leak res in network_init(..)
>=20
> Call freeaddrinfo on it after it's been used
>=20
> CID: 1225050
>=20
> r300972 (by markj):
>=20
> Fix rpcbind init after r300941.
>=20
> - getaddrinfo() sets res =3D NULL on failure and freeaddrinfo() always
>  dereferences its argument, so we should only free the address list =
after
>  a successful call.
> - Address a second potential leak caused by getaddrinfo(AF_INET6)
>  overwriting the address list returned by getaddrinfo(AF_INET).
>=20
> X-MFC-With:	r300941
>=20
> r300973:
>=20
> Follow up to r300932
>=20
> In the event MK_INET6 !=3D no in userspace, but is disabled in the
> kernel, or if there aren't any IPv6 addresses configured in userspace
> (for lo0 and all physical interfaces), rpcbind would terminate
> immediately instead of silently failing on
>=20
> Skip over the IPv6 block to its respective cleanup with freeifaddrs if
> creating the socket failed instead of terminating rpcbind immediately
>=20
> 301649 by ngie:
> MFstable/10 r301648:
>=20
> MFC r300947:
>=20
> Staticize variables only used in rpcbind.c
>=20
> This is some low hanging fruit necessary for making this WARNS?=3D 6 =
clean
>=20
> 301647 by ngie:
> MFstable/10 r301646:
>=20
> MFC r300945:
>=20
> Remove unnecessary caller_uaddr !=3D NULL test before calling free on =
it
>=20
> 301645 by ngie:
> MFstable/10 r301644:
>=20
> MFC r300942:
>=20
> Remove a useless if (x !=3D NULL) check before calling free on =
allocated_uaddr
>=20
> 301643 by ngie:
> MFC r300932,r300934,r300941,r300972,r300973:
>=20
> r300932:
>=20
> Catch malloc(3) errors and socket(2) errors
>=20
> - malloc failing will result in a delayed segfault
> - socket failing will result in delayed failures with setsockopt
>=20
> Exit in the event that either of these high-level conditions are met.
>=20
> CID: 976288, 976321, 976858
>=20
> r300934:
>=20
> Plug leak with ifp by calling freeifaddrs after calling getifaddrs
>=20
> Obtained from: NetBSD v1.18
>=20
> r300941:
>=20
> Don't leak res in network_init(..)
>=20
> Call freeaddrinfo on it after it's been used
>=20
> CID: 1225050
>=20
> r300972 (by markj):
>=20
> Fix rpcbind init after r300941.
>=20
> - getaddrinfo() sets res =3D NULL on failure and freeaddrinfo() always
>  dereferences its argument, so we should only free the address list =
after
>  a successful call.
> - Address a second potential leak caused by getaddrinfo(AF_INET6)
>  overwriting the address list returned by getaddrinfo(AF_INET).
>=20
> X-MFC-With:	r300941
>=20
> r300973:
>=20
> Follow up to r300932
>=20
> In the event MK_INET6 !=3D no in userspace, but is disabled in the
> kernel, or if there aren't any IPv6 addresses configured in userspace
> (for lo0 and all physical interfaces), rpcbind would terminate
> immediately instead of silently failing on
>=20
> Skip over the IPv6 block to its respective cleanup with freeifaddrs if
> creating the socket failed instead of terminating rpcbind immediately
>=20
> 301642 by ngie:
> MFstable/10 r296994:
> r296994 (by asomers):
>=20
> MFC r293229, r293833 to usr.sbin/rpcbind
>=20
> r293833 | asomers | 2016-01-13 10:33:50 -0700 (Wed, 13 Jan 2016) | 16 =
lines
>=20
> Fix Coverity warnings regarding r293229
>=20
> rpcbind/check_bound.c
>        Fix CID1347798, a memory leak in mergeaddr.
>=20
> rpcbind/tests/addrmerge_test.c
>        Fix CID1347800 through CID1347803, memory leaks in ATF tests.  =
They
>        are harmless because each ATF test case runs in its own =
process, but
>        they are trivial to fix.  Fix a few other leaks that Coverity =
didn't
>        detect, too.
>=20
> r293229 | asomers | 2016-01-05 17:00:11 -0700 (Tue, 05 Jan 2016) | 36 =
lines
>=20
> "source routing" in rpcbind
>=20
> Fix a bug in rpcbind for multihomed hosts. If the server had =
interfaces on
> two separate subnets, and a client on the first subnet contacted =
rpcbind at
> the address on the second subnet, rpcbind would advertise addresses on =
the
> first subnet. This is a bug, because it should prefer to advertise the
> address where it was contacted. The requested service might be =
firewalled
> off from the address on the first subnet, for example.
>=20
> usr.sbin/rpcbind/check_bound.c
>        If the address on which a request was received is known, pass =
that
>        to addrmerge as the clnt_uaddr parameter. That is what =
addrmerge's
>        comment indicates the parameter is supposed to mean. The =
previous
>        behavior is that clnt_uaddr would contain the address from =
which the
>        client sent the request.
>=20
> usr.sbin/rpcbind/util.c
>        Modify addrmerge to prefer to use an IP that is equal to =
clnt_uaddr,
>        if one is found. Refactor the relevant portion of the function =
for
>        clarity, and to reduce the number of ifdefs.
>=20
> etc/mtree/BSD.tests.dist
> usr.sbin/rpcbind/tests/Makefile
> usr.sbin/rpcbind/tests/addrmerge_test.c
>        Add unit tests for usr.sbin/rpcbind/util.c:addrmerge.
>=20
> usr.sbin/rpcbind/check_bound.c
> usr.sbin/rpcbind/rpcbind.h
> usr.sbin/rpcbind/util.c
>        Constify some function arguments

My bad =E2=80=94 the compilation error with bsnmp should be fixed by =
r301690.
Thanks,
-Ngie

--Apple-Mail=_9BDA0B6D-93F0-4FFA-A738-464F3DB72F68
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJXWHLCAAoJEPWDqSZpMIYVCekP/0lzEo898+sWIGwYcTAyyIkn
olwk89vVN9wF/TItj5z/O8y3O6kZbhQH7lZNuNOOueQb3ls5js7LGpK5o/A1I/EB
x7yQffEf8QEzqvW9fqvwrrfY3sx+KmJhi9SDlPfvAaec+oZN15vE5CPWZAgtEGZH
5rdame1R6G+kRP62ETPz2y0m+Ysz0HH32KonM5tgeIRaDYkBq+sYsJEXB7x5j1a5
QybA+4SgRXit6u76fCmUgX8QYEaLSJ1F/Bmb3ZLfACD8XLmEu4OvZQUImHIz1mzG
lY91vwJearUtC9R9/3H5vhtgKYO9Me9WfepfjnazvewM9ittZyLxdldlvP4wUwo6
89jPEXOTnOn5+plynzucPIAc6HG0BsGzK01gotgELEwQCXvuVIIPRHzO0H10Wc4q
PpMaJi9uV71kuD6xiHOCK2Az4EcaFe7AtLRQoPyo4moZjtqcN/e7oqeeNB+9vDOC
7AbyKIveWTVK6vwPqYINvSA1puotp5LNOX8MfrZLmzReyjQXehkBH9Inng+yP3JF
XHH5BYIXXorMeaftfOQ3F9tq4L7OVQJ9xBrymF3vpKyejmB7vuBnNlRLPhALAMdJ
/2M58pHBqp+CwdmhrKzgN7QbcIsR+VVSQeiY9BexLkzmqfiksDlYzeDmA1VJqmLa
2aNfr5T3kQ2evZfvKSD3
=aowv
-----END PGP SIGNATURE-----

--Apple-Mail=_9BDA0B6D-93F0-4FFA-A738-464F3DB72F68--

---

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86360996-66C7-402B-90F6-E90F66F5C3EA>

Legal Notices | © 1995-2024 The FreeBSD Project. All rights reserved.

Contact