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
perl won't alarm?
I have code that executes an external command, vis:
eval {
local $SIG{ALRM} = sub { die alarm\n };
alarm $TIMEOUT;
$text = `$pre_command$host $post_command` || ( $connectOk = 0 );
alarm 0;
$errStr = $^E;
};
The command hangs for a reason I don't understand (its a PsExec of opmnctl
@cluster status -app on a windows oracle server). Unfortunately, the block
above never exits.
Is there a way I can protect my routine from hanging system calls?
--
Dr. Robert Woody Security, Privacy, Wireless, and
Weaver Information Assurance
IT Security Architect Cell: 301-524-8138
--
I have great faith in fools -- self confidence my friends call it.
-- Edgar Allan Poe
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: perl won't alarm?
On Wed, 23 Feb 2011, Robert W Weaver wrote: Is there a way I can protect my routine from hanging system calls? alarm() will not interrupt a blocking system call on Windows. If you want to timeout on subprocesses, then you may want to look at Win32::Job. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
