[Bug gold/10708] "out of file descriptors and couldn't close any" -- probably fd leak

[ccoutant at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10708

--- Comment #9 from Cary Coutant <ccoutant at google dot com> 2010-10-23 
01:05:41 UTC ---
I've been trying to track down possible sources of file descriptor leakage.
I've found one:

In copy_relocs.cc, Copy_relocs::emit_copy_reloc():

  typename elfcpp::Elf_types<size>::Elf_WXword addralign =
    sym->object()->section_addralign(shndx);

This, and probably other similar places where we go back to an ELF file for
some info, seems to be leaking file descriptors. The call to
section_addralign() creates an Object::View, and reopens the file descriptor,
but never releases it. Also, at least in this particular case, we're accessing
a different file from the one we currently have locked (the shared library that
contains the definition of the symbol), and we haven't locked the file. If we
had locked the file here, the descriptor would have been released, but I'm not
sure it's safe to lock the shared library at this point -- we're in a
Scan_relocs task, which isn't necessarily single threaded.

I'm wondering whether it would be better to just find and eradicate places
where we need to read a file outside of the times we normally have the file
open.

I have no idea whether this is the cause of the problem reported here, but a
good way to tell is if you can rerun the link with -Wl,--debug=task. That would
give us an idea of where it is when you finally run out of file descriptors.
For this leakage to cause real problems, you'll need lots of shared libraries,
and COPY relocations into lots of them. It seems unlikely, but it's worth a
shot. It's also possible that there are other leakages similar to this that
would trigger under different conditions.

-cary

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.