Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 08 Sep 2015 21:39:52 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 148581] [libc] fopen(3) fails with EMFILE if there are more than SHORT_MAX fds open
Message-ID:  <bug-148581-8-LhHCtlSKQG@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-148581-8@https.bugs.freebsd.org/bugzilla/>
References:  <bug-148581-8@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148581

Karl Young <freebsd@kipshouse.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |freebsd@kipshouse.org

--- Comment #3 from Karl Young <freebsd@kipshouse.org> ---
We've run into this on 9.2.  We're using OpenSource software that uses popen()
to run external commands.  Since popen() returns FILE*, it fails when we get to
32K open files.  This seems to be rarely hit (no comments since 2011), but it
can be a show-stopper.

The only workaround I see in our case is to roll our own popen().

BTW in comment 1:

> with a 32-bit file descriptor field. If the file descriptor exceeds 32767, the 16-bit > field then contains -1 and fileno() in old binaries will return that.

I think this fails when FD gets to 64K and the short version starts counting up
from 0 again.

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-148581-8-LhHCtlSKQG>