Re: File descriptor leak involving kqueue

Eric Haszlakiewicz writes: > For cross-OS support you'll need to add a configure check for that. > In some environments it seems that the memory leak can't be fixed, > since res_ndestroy doesn't exist. Looks that way -- Linux doesn't even have res_nclose(), so I guess

Re: update on reproducible builds

In article <20161219041741.d824f17f...@rebar.astron.com>, Christos Zoulas wrote: > >I have changed the CVS server on cvs.netbsd.org, not to do this >anymore and always provide the timestamps to the client, which >means that even "cvs update" now sets the time for updated

update on reproducible builds

Hello, Since yesterday the releng build server has been updated to run "build.sh -P", which sets MKREPRO and MKREPRO_TIMESTAMP automatically. For those not familiar with those options, the first variable arranges things so programs don't contain build-specific dates/times etc.; the second

Re: 7.99.50 complete hang

> On 18 Dec 2016, at 21:49, Joerg Sonnenberger wrote: > > On Sun, Dec 18, 2016 at 09:45:00PM +0100, Joerg Sonnenberger wrote: >> On Fri, Dec 16, 2016 at 01:14:10AM +0100, Thomas Klausner wrote: >>> When I start my chrooted bulkbuild, the system completely stops. It >>> prints a

Re: 7.99.50 complete hang

On Sun, Dec 18, 2016 at 09:45:00PM +0100, Joerg Sonnenberger wrote: > On Fri, Dec 16, 2016 at 01:14:10AM +0100, Thomas Klausner wrote: > > When I start my chrooted bulkbuild, the system completely stops. It > > prints a couple of dots (like when it farms out the first steps of the > > dependency

Re: 7.99.50 complete hang

On Fri, Dec 16, 2016 at 01:14:10AM +0100, Thomas Klausner wrote: > When I start my chrooted bulkbuild, the system completely stops. It > prints a couple of dots (like when it farms out the first steps of the > dependency chain computation) and then nothing. When I try to open a > second shell in

Re: File descriptor leak involving kqueue

On 12/18/2016 7:56 AM, Tom Ivar Helbekkmo wrote: Joerg Sonnenberger writes: It seems pretty obvious that OpenDMARC is not correctly managing ressources. It creates an on-stack res_state, initialized it with res_ninit, but never destroys it. Ah! I didn't catch that - thanks!

Re: File descriptor leak involving kqueue

In article <20161218124436.ga8...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Tue, Dec 13, 2016 at 07:58:22PM +0100, Tom Ivar Helbekkmo wrote: >> Lately, I'm running my postfix with opendkim and opendmarc milters (both >> from pkgsrc). Something about opendmarc is bleeding

Re: File descriptor leak involving kqueue

Joerg Sonnenberger writes: > It seems pretty obvious that OpenDMARC is not correctly managing > ressources. It creates an on-stack res_state, initialized it with > res_ninit, but never destroys it. Ah! I didn't catch that - thanks! I'll modify OpenDMARC to use res_ndestroy()

Re: File descriptor leak involving kqueue

On Tue, Dec 13, 2016 at 07:58:22PM +0100, Tom Ivar Helbekkmo wrote: > Lately, I'm running my postfix with opendkim and opendmarc milters (both > from pkgsrc). Something about opendmarc is bleeding the system empty of > file handles, and I'd appreciate some help thinking about how to find > out

Re: File descriptor leak involving kqueue

Robert Swindells writes: > I think that close() of a socket can leak the kevent(2) structures > if there are some still active. No, I think something else is going on, and it's in the resolver. In lib/libc/resolv/res_send.c, in the function res_nsend(), res_check() is called,

Automated report: NetBSD-current/i386 build success

The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2016.12.18.06.56.43 nonaka src/external/intel-fw-public/iwl3160/Makefile,v 1.2 2016.12.18.06.56.43 nonaka