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

Inside perl -d in a loaded .pm file, a global lexical hash is empty in the second function that follows it #15027

Closed
p5pRT opened this issue Nov 3, 2015 · 10 comments

Comments

@p5pRT
Copy link

p5pRT commented Nov 3, 2015

Migrated from rt.perl.org#126552 (status was 'rejected')

Searchable as RT126552$

@p5pRT
Copy link
Author

p5pRT commented Nov 3, 2015

From @shlomif

Hi all,

this is what appears to be a bug that affects perl -d and that happens in all
versions of perl that I tried from perl-5.8.9 to bleadperl. To reproduce save
the files (or clone the Git repository from here -
https://github.com/shlomif/possible-perl-d-bug-via-ProjectEuler377 ), run bash
invoke-debugger.bash and source "cmds.perldb". As can be seen the debugger sees
%mult_cache as empty when being evaluated in the second subroutine after which
it was declared.

This should be easy to rework into a patch of a test (but without a fix).

Regards,

  Shlomi Fish

--

@p5pRT
Copy link
Author

p5pRT commented Nov 3, 2015

From @shlomif

cmds.perldb

@p5pRT
Copy link
Author

p5pRT commented Nov 3, 2015

From @shlomif

euler377-test-1.pl

@p5pRT
Copy link
Author

p5pRT commented Nov 3, 2015

From @shlomif

Euler377.pm

@p5pRT
Copy link
Author

p5pRT commented Nov 3, 2015

From @shlomif

invoke-debugger.bash

@p5pRT
Copy link
Author

p5pRT commented Nov 6, 2015

From @iabyn

On Tue, Nov 03, 2015 at 05​:32​:25AM -0800, shlomif@​shlomifish.org wrote​:

this is what appears to be a bug that affects perl -d and that happens in all
versions of perl that I tried from perl-5.8.9 to bleadperl. To reproduce save
the files (or clone the Git repository from here -
https://github.com/shlomif/possible-perl-d-bug-via-ProjectEuler377 ), run bash
invoke-debugger.bash and source "cmds.perldb". As can be seen the debugger sees
%mult_cache as empty when being evaluated in the second subroutine after which
it was declared.

This is normal closure behaviour. Here's a simpler example that doesn't
involve the debugger. This​:

  {
  my $x = 1;
  sub f1 { $x; print "f1​: x=", eval'$x', "\n"; }
  sub f2 { print "f2​: x=", eval'$x', "\n"; }
  }
  f1();
  f2();

outputs​:

  f1​: x=1
  f2​: x=

After $x has gone out of scope, it can only be seen by subs that have
closed over it.

In your original example, the lexical goes out of scope after the .pm file
has been loaded and executed, and the debugger does the equivalent of
eval to display variables.

--
"Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit."
  -- Lady Croom, "Arcadia"

@p5pRT
Copy link
Author

p5pRT commented Nov 6, 2015

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

@p5pRT
Copy link
Author

p5pRT commented Nov 12, 2015

From @shlomif

Hi Dave,

thanks for your reply.

That put aside, rt.perl.org/rt.cpan.org/etc. should really​:

1. Provide a WWW "http​://" hyperlink back to the bug report's web page in the
text message.

2. Make sure it doesn't keep logging one's out repetitively after one closes
the browser.

Both of these problems make for a bad user-experience for me when using
rt.perl.org/rt.cpan.org , make me annoyed and may make Perl look bad.

See below for the rest of my reply.

On Fri, 6 Nov 2015 03​:31​:02 -0800
"Dave Mitchell via RT" <perlbug-followup@​perl.org> wrote​:

On Tue, Nov 03, 2015 at 05​:32​:25AM -0800, shlomif@​shlomifish.org wrote​:

this is what appears to be a bug that affects perl -d and that happens in
all versions of perl that I tried from perl-5.8.9 to bleadperl. To
reproduce save the files (or clone the Git repository from here -
https://github.com/shlomif/possible-perl-d-bug-via-ProjectEuler377 ), run
bash invoke-debugger.bash and source "cmds.perldb". As can be seen the
debugger sees %mult_cache as empty when being evaluated in the second
subroutine after which it was declared.

This is normal closure behaviour. Here's a simpler example that doesn't
involve the debugger. This​:

\{
    my $x = 1;
    sub f1 \{ $x; print "f1&#8203;: x="\, eval'$x'\, "\\n"; \}
    sub f2 \{     print "f2&#8203;: x="\, eval'$x'\, "\\n"; \}
\}
f1\(\);
f2\(\);

outputs​:

f1&#8203;: x=1
f2&#8203;: x=

After $x has gone out of scope, it can only be seen by subs that have
closed over it.

In your original example, the lexical goes out of scope after the .pm file
has been loaded and executed, and the debugger does the equivalent of
eval to display variables.

I see. It seems like an undesirable behaviour to me. Is it done this way due to
speed concerns?

Regards,

  Shlomi Fish

--


Shlomi Fish http​://www.shlomifish.org/
List of Text Processing Tools - http​://shlom.in/text-proc

Chuck Norris has conceived a master plan that does not involve building a time
machine, and if you claim it isn’t good, you’ll be dead.
  — http​://www.shlomifish.org/humour/bits/facts/Chuck-Norris/

Please reply to list if it's a mailing list post - http​://shlom.in/reply .

@p5pRT
Copy link
Author

p5pRT commented Nov 18, 2015

From @iabyn

On Thu, Nov 12, 2015 at 01​:18​:00PM +0200, Shlomi Fish wrote​:

That put aside, rt.perl.org/rt.cpan.org/etc. should really​:

1. Provide a WWW "http​://" hyperlink back to the bug report's web page in the
text message.

2. Make sure it doesn't keep logging one's out repetitively after one closes
the browser.

Both of these problems make for a bad user-experience for me when using
rt.perl.org/rt.cpan.org , make me annoyed and may make Perl look bad.

I have no involvement with the RT infratructurem, so cant rally comment on
it.

This is normal closure behaviour. Here's a simpler example that doesn't
involve the debugger. This​:

\{
    my $x = 1;
    sub f1 \{ $x; print "f1&#8203;: x="\, eval'$x'\, "\\n"; \}
    sub f2 \{     print "f2&#8203;: x="\, eval'$x'\, "\\n"; \}
\}
f1\(\);
f2\(\);

outputs​:

f1&#8203;: x=1
f2&#8203;: x=

After $x has gone out of scope, it can only be seen by subs that have
closed over it.

In your original example, the lexical goes out of scope after the .pm file
has been loaded and executed, and the debugger does the equivalent of
eval to display variables.

I see. It seems like an undesirable behaviour to me. Is it done this way
due to speed concerns?

It's a basic property of closures, and it's desirable, to avoid lots of
leaks. Consider the following simple Foo.pm file​:

  package Foo;
  my $x = bless [], 'Foo';

  sub bar { eval '$x' }
  1;

In perl currently, the $x lexical is created at the time Foo.pm is
required, and is freed (and its destructor called) at the end of the
require. If Foo​::bar() is subsequently called, perl will warn

  Variable "$x" is not available at (eval 1)

and will return an undef value.

If perl were to delay freeing $x in case some sub in the current scope
might later eval it, it would have to avoid freeing many things.

If that sub were written as

  sub bar { $x; eval '$x' }

then it becomes a closure, closing over $x; and in this case, the freeing
of $x *is* delayed until &Foo​::bar is destroyed, typically during global
destruction at program exit.

--
Music lesson​: a symbiotic relationship whereby a pupil's embellishments
concerning the amount of practice performed since the last lesson are
rewarded with embellishments from the teacher concerning the pupil's
progress over the corresponding period.

@p5pRT p5pRT closed this as completed Mar 25, 2016
@p5pRT
Copy link
Author

p5pRT commented Mar 25, 2016

@iabyn - Status changed from 'open' to 'rejected'

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

No branches or pull requests

1 participant