https://sourceware.org/bugzilla/show_bug.cgi?id=19260
Bug ID: 19260
Summary: 32-bit Solaris libc has a limit of maximum 255 open
file descriptors
Product: binutils
Version: 2.25
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: stefan.teleman at oracle dot com
Target Milestone: ---
Created attachment 8792
--> https://sourceware.org/bugzilla/attachment.cgi?id=8792&action=edit
cache.c.patch
The 32-bit Solaris libc (both on Intel and SPARC) can only handle 255
open file descriptors. The reason for this limitation in 2015 is historical.
To make things worse: a process can call setrlimit(RLIMIT_NOFILE, &rlim)
and raise the current number of allowable file descriptors to more than 255.
But this doesn't mean that libc will actually be able to handle them without
some additional acrobatics. This will lead to a very interesting situation:
a caller can call getrlimit(RLIMIT_NOFILE, &rlim), and obtain a value for
rlim.rlim_cur that is invalid in 32-bit Solaris libc.
Unfortunately, this is what is happening in binutils 2.25.1,
in ${top_srcdir}/bfd/cache.c. The function
static int bfd_cache_max_open (void);
will try to determine how many file descriptors it can cache based on the
result from getrlimit(2). If a binutils program is running from within
another program which has raised RLIMIT_NOFILE to 65536 (for example), libbfd
will correctly assume that 8192 file descriptors are safe to cache (65536 / 8).
Unfortunately, that is not the case in Solaris 32-bit libc.
I am proposing a Solaris-specific patch here, which deals with this problem.
It is not elegant by any means, but it cures this problem in Solaris 32-bit,
and without affecting any other bfd target.
64-bit Solaris libc does not have this limitation.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
