New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
File handles opened via scalar reference have extra refcount #15225
Comments
From andrew.gregory.8@gmail.comFollowing commit 7bdb4ff, when open is called with a scalar ref, the filehandle has a refcount of 2, preventing it from being closed when the variable goes out of scope. { This pattern is used by modules such as Win32::LongPath (https://github.com/rdboisvert/Win32-LongPath/blob/8faa348/lib/Win32/LongPath.pm#L485). |
From @cpansproutOn Fri Mar 11 07:38:26 2016, agregory wrote:
Ever since Perl 5.6, this type of open has vivified a glob with a name like *_GEN_0. In your example, \*_GEN_0 == $fh will be true after opening the handle. The reason it is not freed when $fh goes out of scope is that the stash holds a reference to the handle, too. There are two conceivable ways to solve this. 1) Don’t vivify a handle in the stash, but create an ‘anonymous’ handle named __ANONIO__, which already happens with other variations of the syntax. 2) Vivify a typeglob, but not in the stash (like __ANONIO__), but call in _GEN_0. Whether we can do either depends on the answers to these questions: • Is anybody depending on the name? (It certainly makes debugging easier than having multiple handles all named __ANONIO__.) • Is anybody depending on being able to look up the name in the stash and find that same handle? I don’t know the answers to those questions, which makes it hard to decide how to proceed. I would like to think that the answer to the second question is no (that nobody needs to access such filehandles by name). -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
Migrated from rt.perl.org#127692 (status was 'open')
Searchable as RT127692$
The text was updated successfully, but these errors were encountered: