Skip to content
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

Open
p5pRT opened this issue Mar 11, 2016 · 3 comments
Open

File handles opened via scalar reference have extra refcount #15225

p5pRT opened this issue Mar 11, 2016 · 3 comments

Comments

@p5pRT
Copy link

p5pRT commented Mar 11, 2016

Migrated from rt.perl.org#127692 (status was 'open')

Searchable as RT127692$

@p5pRT
Copy link
Author

p5pRT commented Mar 11, 2016

From andrew.gregory.8@gmail.com

Following 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.

{
  use B;
  my $fh;
  open ${ \$fh }, '<', $^X;
  print B​::svref_2object( $fh )->REFCNT; # prints 2
}

This pattern is used by modules such as Win32​::LongPath (https://github.com/rdboisvert/Win32-LongPath/blob/8faa348/lib/Win32/LongPath.pm#L485).

@p5pRT
Copy link
Author

p5pRT commented Mar 12, 2016

From @cpansprout

On Fri Mar 11 07​:38​:26 2016, agregory wrote​:

Following 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.

{
use B;
my $fh;
open ${ \$fh }, '<', $^X;
print B​::svref_2object( $fh )->REFCNT; # prints 2
}

This pattern is used by modules such as Win32​::LongPath
(https://github.com/rdboisvert/Win32-
LongPath/blob/8faa348/lib/Win32/LongPath.pm#L485).

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

@p5pRT
Copy link
Author

p5pRT commented Mar 12, 2016

The RT System itself - Status changed from 'new' to 'open'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants