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
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: 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?
On Wed, 23 Feb 2011 16:33:49 +0100, Brian Raven 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
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
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?
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 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
