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