There are ld_plugin_status Plugin_manager::release_input_file(unsigned int handle) { if (this->object(handle) == NULL) return LDPS_BAD_HANDLE; Pluginobj* obj = this->object(handle)->pluginobj(); if (obj == NULL) return LDPS_BAD_HANDLE; obj->unlock(this->task_); return LDPS_OK; } It doesn't close the file descriptor.
A patch is posted at https://sourceware.org/ml/binutils/2015-01/msg00300.html
Do you have a case where gold is running out of file descriptors? Unlocking the file doesn't close the descriptor immediately, but it should make that descriptor available for reuse if needed; see Descriptors::close_some_descriptor().
(In reply to Cary Coutant from comment #2) > Do you have a case where gold is running out of file descriptors? Unlocking > the file doesn't close the descriptor immediately, but it should make that > descriptor available for reuse if needed; see > Descriptors::close_some_descriptor(). See PR 15660.
With this patch: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02508.html Plugin_manager::release_input_file may be called from the claim_file hook. It isn't prepared to deal with it.
(In reply to H.J. Lu from comment #4) > With this patch: > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02508.html > > Plugin_manager::release_input_file may be called from the claim_file hook. > It isn't prepared to deal with it. get_input_file is meant to be called only from the all_symbols_read handler, and release_input_file only on a handle obtained from get_input_file.
Created attachment 8088 [details] A updated patch No need to call release. We only need to deal with called from the claim_file hook.
(In reply to Cary Coutant from comment #5) > (In reply to H.J. Lu from comment #4) > > With this patch: > > > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02508.html > > > > Plugin_manager::release_input_file may be called from the claim_file hook. > > It isn't prepared to deal with it. > > get_input_file is meant to be called only from the all_symbols_read handler, > and release_input_file only on a handle obtained from get_input_file. GCC plugin doesn't use get_input_file. Input file is done when the claim_file hook returns. That is why I call release_input_file in claim_file hook.
*** Bug 15660 has been marked as a duplicate of this bug. ***
The leakage in PR 15660 is due to a failure to unlock the plugin object when a member of a thin archive is claimed by the plugin. The release_input_file API does in fact release the descriptor. Gold does not close descriptors right away -- when it releases a descriptor, it merely becomes available for closing if we run into descriptor pressure later on. As far as this PR is concerned, gold is working as intended. In addition, the release_input_file API was only added to go with the get_input_file API, for use during the all_symbols_read callback. The file descriptor passed to the claim_file callback is managed by the linker and is released automatically when the claim_file handler returns (except for the bug in PR 15660). The LTO plugin should *not* use release_input_file during the claim_file handler.