This is the mail archive of the binutils-cvs@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[binutils-gdb/binutils-2_26-branch] Fix a problem with the maximum number of open files held in the cache when running on a 32-bit Solar


https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3c8c863e905ec0c2b7c003ad951423fd0ff3dcf4

commit 3c8c863e905ec0c2b7c003ad951423fd0ff3dcf4
Author: Stefan Teleman <stefan.teleman@oracle.com>
Date:   Fri Nov 20 15:28:40 2015 +0000

    Fix a problem with the maximum number of open files held in the cache when running on a 32-bit Solaris host.
    
    	PR ld/19260
    	* cache.c (bfd_cache_max_open): Avoid using getrlimit on 32-bit
    	Solaris as the result is unreliable.

Diff:
---
 bfd/ChangeLog |  5 +++++
 bfd/cache.c   | 24 +++++++++++++++++++++---
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/bfd/ChangeLog b/bfd/ChangeLog
index 80a5b2d..3194cc3 100644
--- a/bfd/ChangeLog
+++ b/bfd/ChangeLog
@@ -1,6 +1,11 @@
 2015-12-10  Alan Modra  <amodra@gmail.com>
 
 	Apply from master.
+	2015-11-20  Stefan Teleman  <stefan.teleman@oracle.com>
+	PR ld/19260
+	* cache.c (bfd_cache_max_open): Avoid using getrlimit on 32-bit
+	Solaris as the result is unreliable.
+
 	2015-11-18  Alan Modra  <amodra@gmail.com>
 	PR 19256
 	* archive.c (bfd_generic_openr_next_archived_file): Don't allow
diff --git a/bfd/cache.c b/bfd/cache.c
index 94a82da..8c9a238 100644
--- a/bfd/cache.c
+++ b/bfd/cache.c
@@ -78,18 +78,36 @@ bfd_cache_max_open (void)
   if (max_open_files == 0)
     {
       int max;
+#if defined(__sun) && !defined(__sparcv9) && !defined(__x86_64__)
+      /* PR ld/19260: 32-bit Solaris has very inelegant handling of the 255
+	 file descriptor limit.  The problem is that setrlimit(2) can raise
+	 RLIMIT_NOFILE to a value that is not supported by libc, resulting
+         in "Too many open files" errors.  This can happen here even though
+	 max_open_files is set to rlim.rlim_cur / 8.  For example, if
+	 a parent process has set rlim.rlim_cur to 65536, then max_open_files
+	 will be computed as 8192.
+
+	 This check essentially reverts to the behavior from binutils 2.23.1
+         for 32-bit Solaris only.  (It is hoped that the 32-bit libc
+	 limitation will be removed soon).  64-bit Solaris libc does not have
+	 this limitation.  */
+      max = 16;
+#else
 #ifdef HAVE_GETRLIMIT
       struct rlimit rlim;
+
       if (getrlimit (RLIMIT_NOFILE, &rlim) == 0
 	  && rlim.rlim_cur != (rlim_t) RLIM_INFINITY)
 	max = rlim.rlim_cur / 8;
       else
-#endif /* HAVE_GETRLIMIT */
+#endif
 #ifdef _SC_OPEN_MAX
 	max = sysconf (_SC_OPEN_MAX) / 8;
 #else
-	max = 10;
-#endif /* _SC_OPEN_MAX */
+        max = 10;
+#endif
+#endif /* not 32-bit Solaris */
+
       max_open_files = max < 10 ? 10 : max;
     }


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]