[Bug binutils/23460] regression: ar can not create archive containing many (>1024) lto object files

[zenith432 at users dot sourceforge.net]

https://sourceware.org/bugzilla/show_bug.cgi?id=23460

--- Comment #3 from zenith432 at users dot sourceforge.net ---
This patch should fix it

===== Begin Patch
diff --git a/bfd/plugin.c b/bfd/plugin.c
index 7c5bba22..98c79c87 100644
--- a/bfd/plugin.c
+++ b/bfd/plugin.c
@@ -209,8 +209,7 @@ try_claim (bfd *abfd)
   if (!bfd_plugin_open_input (abfd, &file))
     return 0;
   claim_file (&file, &claimed);
-  if (!claimed)
-    close (file.fd);
+  close (file.fd);
   return claimed;
 }

@@ -223,6 +222,9 @@ try_load_plugin (const char *pname, bfd *abfd, int
*has_plugin_p)
   ld_plugin_onload onload;
   enum ld_plugin_status status;

+  if (claim_file)
+    goto have_claim_file;
+
   *has_plugin_p = 0;

   plugin_handle = dlopen (pname, RTLD_NOW);
@@ -257,6 +259,7 @@ try_load_plugin (const char *pname, bfd *abfd, int
*has_plugin_p)
   if (status != LDPS_OK)
     goto err;

+have_claim_file:
   *has_plugin_p = 1;

   abfd->plugin_format = bfd_plugin_no;
===== End Patch

There are two leaks there
- try_load_plugin() (in bfd/plugin.c) calls dlopen() and onload() again and
again to load the plugin for each object file processed via
bfd_plugin_object_p.  There is no intervening dlclose() and the plugin memory
is not cleaned up.  Moreover, add_symbols() keeps the syms array along with the
symbol name strings that were allocated by the plugin.  Presumably this memory
is released via the plugin's cleanup_handler which is not interfaced and never
called.
It is ok I think to keep the plugin loaded permanently, but calling dlopen()
over and over increases its refcount and calling onload() over and over is a
violation of the plugin API.  onload() should be called once, and claim_file
can be called any number of times.  So the patch skips the dlopen() and
onload() if claim_file is already registered.

Note however, that calling claim_file many times for 1000s of LTO objects
allocates memory each time (for the symbols passed in via add_symbols) and this
memory is not released (it is kept used from bfd_plugin_canonicalize_symtab). 
So this solution can still potentially run out-of-memory - because the memory
for the symtab passed in to add_symbols() is never released.

- The file descriptor opened for claim_file in try_claim() should always be
closed after it.  The plugin doesn't use the descriptor anymore.  If the plugin
needs a file descriptor again later during the "all symbols read" event, it
calls get_input_file() to get another one.  However, neither
all_symbols_read_handler nor get_input_file are used by bfd/plugin.c.  See the
documentation
http://gcc.gnu.org/wiki/whopr/driver
If the descriptor opened for claim_file is not closed after, it leaks because
nobody closes it.  The add_symbols() callback is called from inside claim_file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.