RE: spurious deaths in script execution due to read-only Config?
I see what ur saying but I guess I see nothing wrong with %Config being read
only and croaking if touched.
At 05:18 PM 2/23/2011 -, Brian Raven wrote:
I do recall 'perldoc perlsub' warning about localising tied hashes
arrays being broken, and %Config::Config is a tied hash, I believe.
Regarding your work around. Map in a void context is usually frowned
upon. Perhaps grep or possibly ...
for ('now') { require ActiveState::Path }
... should have the same effect, i.e. aliasing $_ to something
(hopefully) innocuous.
--
REMEMBER THE WORLD TRADE CENTER ---= WTC 911 =--
...ne cede malis
0100
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: spurious deaths in script execution due to read-only Config?
On Wed, 23 Feb 2011, Brian Raven wrote:
On Wed, 23 Feb 2011, Christian Walde wrote:
Solution: Make sure $_ isn't pointing at %Config when Exporter.pm
happens. This can be done as simple as this:
map { require ActiveState::Path } 1;
(Though i'm sure more elegant solutions exist.)
[...]
Regarding your work around. Map in a void context is usually frowned
upon. Perhaps grep or possibly ...
for ('now') { require ActiveState::Path }
... should have the same effect, i.e. aliasing $_ to something
(hopefully) innocuous.
It turns out the canonical solution is to add
local *_;
at the top of the subroutine. Read all the gory details in perlsub.pod...
The important part to remember is:
local $_;
is not safe! It does not mean that $_ is now undef and that you can
do whatever you want with it. It may still have magic attached to
it, and (in this case) it may still be associated with a tied hash
or array element.
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: spurious deaths in script execution due to read-only Config?
It's the standard behavior of Perl.
use Data::Dump pp;
%a = qw/x 1 y 1 z 1/;
grep { $_ } $a{bob};
pp %a;
^D
(y, 1, bob, undef, x, 1, z, 1)
At 02:18 PM 2/22/2011 +0100, Christian Walde wrote:
On Tue, 22 Feb 2011 13:46:55 +0100, Chris Wagner wagn...@plebeian.com wrote:
At 08:54 PM 2/21/2011 +0100, Christian Walde wrote:
use Config;
# print 1 if $Config{foo}; # enabling this removes the crash
grep { $_ } $Config{bar}; # this crashes
These two lines on their own will cause ActivePerl of any version to exit
with the error message above.
Hi. U can't do that because Perl must autovivify $Config{bar} in order to
have a value to put into $_. HTH.
Good guess, that's almost what happens. The problem happens a bit deeper in
the guts and is actually caused by Exporter.pm, where it tries to do local
$_ and by doing so triggers autovivification. (grep/map only do an aliasing
of %Config to $_, which is fine.)
I remembered this morning that there is a bug tracker for ActivePerl,
started to write up an error report and in doing so ended up formulating a
possible for for ActiveState: http://bugs.activestate.com/show_bug.cgi?id=89447
--
With regards,
Christian Walde
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
--
REMEMBER THE WORLD TRADE CENTER ---= WTC 911 =--
...ne cede malis
0100
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: spurious deaths in script execution due to read-only Config?
-Original Message-
From: perl-win32-users-boun...@listserv.activestate.com
[mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of
Chris Wagner
Sent: 23 February 2011 14:25
To: perl-win32-users@listserv.activestate.com
Subject: Re: spurious deaths in script execution due to read-only
Config?
It's the standard behavior of Perl.
use Data::Dump pp;
%a = qw/x 1 y 1 z 1/;
grep { $_ } $a{bob};
pp %a;
^D
(y, 1, bob, undef, x, 1, z, 1)
At 02:18 PM 2/22/2011 +0100, Christian Walde wrote:
On Tue, 22 Feb 2011 13:46:55 +0100, Chris Wagner
wagn...@plebeian.com wrote:
At 08:54 PM 2/21/2011 +0100, Christian Walde wrote:
use Config;
# print 1 if $Config{foo}; # enabling this removes the crash
grep { $_ } $Config{bar}; # this crashes
These two lines on their own will cause ActivePerl of any version
to exit
with the error message above.
Hi. U can't do that because Perl must autovivify $Config{bar} in
order to
have a value to put into $_. HTH.
Good guess, that's almost what happens. The problem happens a bit
deeper in
the guts and is actually caused by Exporter.pm, where it tries to do
local
$_ and by doing so triggers autovivification. (grep/map only do an
aliasing
of %Config to $_, which is fine.)
I remembered this morning that there is a bug tracker for ActivePerl,
started to write up an error report and in doing so ended up
formulating a
possible for for ActiveState:
http://bugs.activestate.com/show_bug.cgi?id=89447
While autovivication is part of Perl's normal behaviour, I'm not sure
that it is cause of this problem. The fact that un-commenting the line
before the grep in the OP's code makes the problem go away tends to
confirm this.
I suspect that it is related to the Activestate overriding of Config
('use diagnostics' will give a stack trace) but I can't see how it
causes that error, i.e. %Config::Config is read-only.
Note that inhibiting the activestate override
($ENV{ACTIVEPERL_CONFIG_DISABLE} = 1) also seems to make the problem go
away.
Maybe somebody from Activestate has a clue.
HTH
--
Brian Raven
Please consider the environment before printing this e-mail.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient or have received this e-mail in error, please advise
the sender immediately by reply e-mail and delete this message and any
attachments without retaining a copy.
Any unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: spurious deaths in script execution due to read-only Config?
On Wed, 23 Feb 2011 16:33:49 +0100, Brian Raven bra...@nyx.com wrote:
I remembered this morning that there is a bug tracker for ActivePerl,
started to write up an error report and in doing so ended up
formulating a possible for for ActiveState:
http://bugs.activestate.com/show_bug.cgi?id=89447
It's the standard behavior of Perl.
While autovivication is part of Perl's normal behaviour, I'm not sure
that it is cause of this problem. The fact that un-commenting the line
before the grep in the OP's code makes the problem go away tends to
confirm this.
I suspect that it is related to the Activestate overriding of Config
('use diagnostics' will give a stack trace) but I can't see how it
causes that error, i.e. %Config::Config is read-only.
Note that inhibiting the activestate override
($ENV{ACTIVEPERL_CONFIG_DISABLE} = 1) also seems to make the problem go
away.
Maybe somebody from Activestate has a clue.
Try reading the whole bug i linked. It has a detailed description of what
happens and when and where the offending error is triggered and how it can be
prevented.
Summary:
Grep makes $_ point at $Config{foo}, on first load ActivePerl::Config tries to
load File::Basename, which triggers Exporter.pm, which goes local $_. At THAT
point an attempt to autovivify is made causing the whole thing to crash down.
Solution: Make sure $_ isn't pointing at %Config when Exporter.pm happens. This
can be done as simple as this:
map { require ActiveState::Path } 1;
(Though i'm sure more elegant solutions exist.)
--
With regards,
Christian Walde
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: spurious deaths in script execution due to read-only Config?
-Original Message-
From: perl-win32-users-boun...@listserv.activestate.com
[mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of
Christian Walde
Sent: 23 February 2011 15:57
To: perl-win32-users@listserv.activestate.com
Subject: Re: spurious deaths in script execution due to read-only
Config?
...
Try reading the whole bug i linked. It has a detailed description of
what happens and when and where the
offending error is triggered and how it can be prevented.
Summary:
Grep makes $_ point at $Config{foo}, on first load ActivePerl::Config
tries to load File::Basename, which
triggers Exporter.pm, which goes local $_. At THAT point an attempt
to autovivify is made causing the whole thing to crash down.
Solution: Make sure $_ isn't pointing at %Config when Exporter.pm
happens. This can be done as simple as this:
map { require ActiveState::Path } 1;
(Though i'm sure more elegant solutions exist.)
Right, I hadn't followed that link.
I do recall 'perldoc perlsub' warning about localising tied hashes
arrays being broken, and %Config::Config is a tied hash, I believe.
Regarding your work around. Map in a void context is usually frowned
upon. Perhaps grep or possibly ...
for ('now') { require ActiveState::Path }
... should have the same effect, i.e. aliasing $_ to something
(hopefully) innocuous.
HTH
--
Brian Raven
Please consider the environment before printing this e-mail.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient or have received this e-mail in error, please advise
the sender immediately by reply e-mail and delete this message and any
attachments without retaining a copy.
Any unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: spurious deaths in script execution due to read-only Config?
Hi. U can't do that because Perl must autovivify $Config{bar} in order to
have a value to put into $_. HTH.
At 08:54 PM 2/21/2011 +0100, Christian Walde wrote:
use Config;
# print 1 if $Config{foo}; # enabling this removes the crash
grep { $_ } $Config{bar}; # this crashes
These two lines on their own will cause ActivePerl of any version to exit
with the error message above. I'm not sure what exactly causes this or
whether i should send this to the p5p mailing list, but i figured here is
better for a start.
--
REMEMBER THE WORLD TRADE CENTER ---= WTC 911 =--
...ne cede malis
0100
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: spurious deaths in script execution due to read-only Config?
On Tue, 22 Feb 2011 13:46:55 +0100, Chris Wagner wagn...@plebeian.com wrote:
At 08:54 PM 2/21/2011 +0100, Christian Walde wrote:
use Config;
# print 1 if $Config{foo}; # enabling this removes the crash
grep { $_ } $Config{bar}; # this crashes
These two lines on their own will cause ActivePerl of any version to exit
with the error message above.
Hi. U can't do that because Perl must autovivify $Config{bar} in order to
have a value to put into $_. HTH.
Good guess, that's almost what happens. The problem happens a bit deeper in the
guts and is actually caused by Exporter.pm, where it tries to do local $_ and
by doing so triggers autovivification. (grep/map only do an aliasing of %Config
to $_, which is fine.)
I remembered this morning that there is a bug tracker for ActivePerl, started
to write up an error report and in doing so ended up formulating a possible for
for ActiveState: http://bugs.activestate.com/show_bug.cgi?id=89447
--
With regards,
Christian Walde
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
