[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 #5 from zenith432 at users dot sourceforge.net ---
Correction:

After another review, I noticed that the gcc plugin does NOT free the syms
array passed to add_symbols() during cleanup_hook().  This array is freed
during the all_symbols_read_hook(), and cleanup_hook() assumes it's already
free.

So...  it's hopeless to prevent a memory leak for what bfd/plugin.c is doing

A file descriptor leak can still be avoided because...
- for the gcc plugin - doesn't use fd after claim_file_hook().
- as I said, the llvm plugin uses fd as an index to detect which input files
come from the same archive - but this does not mess it up for what bfd/plugin.c
is doing.  If fd is closed and its value is reused, llvm plugin incorrectly
concludes that all input files with the same fd come from the same archive. 
But this only messes it up in all_symbols_read_hook() when using an llvm
feature called "thinlto" with a "-thinlto" option passed to the plugin.

So... I believe the patch in Comment 3 is ok.  At least for the 2 plugins the
way they are today.

I noticed one more potential leak of fd though... in bfd_plugin_open_input()

=====
--- a/bfd/plugin.c
+++ b/bfd/plugin.c
@@ -187,7 +187,10 @@ bfd_plugin_open_input (bfd *ibfd, struct
ld_plugin_input_file *file)
     {
       struct stat stat_buf;
       if (fstat (file->fd, &stat_buf))
-       return 0;
+       {
+         close(file->fd);
+         return 0;
+       }
       file->offset = 0;
       file->filesize = stat_buf.st_size;
     }
=====

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