I've inherited some Perl code that runs on a Linux server just fine. I'm in the process of getting it to run on Windows XP, ActiveState Perl 5.16.2, and a BitNami WAMP stack. (Note: this setup is already running my Perl .cgi programs so this is a working setup.)
Anyway the "main" Perl program--let's call it main.cgi--has this statement:
require("extra/stuff_1.cgi");
When main.cgi runs, an error occurs:
C:/BitNami/apache2/cgi-bin/extra/stuff_1.cgi did not return a true value at C:/BitNami/apache2/cgi-bin/main.cgi line XX.
Now here's what is weird: stuff_1.cgi ends with 1; (i.e., it is the last line in the file)!
I've even commented out the code in the functions within stuff_1.cgi -- which are mostly functions with Here Documents, e.g.
sub func {
return <<EOF;
...
EOF
}
making it contain just
sub func {
#
#return <<EOF;
#...
#EOF
}
etc.
and yet the "did not return a true value" still occurs!
However if I delete all the code so stuff_1.cgi contains
1;
the error goes away (as it should).
stuff_1.cgi passes perl -c, even with use strict and use warnings
ETA: If I copy the contents of stuff_1.cgi and paste it into main.cgi (replacing the require statement), the code works just fine.
I've never seen anything like this before; what could possibly be the cause?
Why is the debugger not working (ActiveState or Strawberry Perl under Windows)?
Why is the debugger not working [ActiveState or Strawberry Perl under Windows]?
A recent release of PathTools (part of Perl distribution, file Cwd.pm) unfortunately contains a bug which breaks EPIC's debugger frontend. The specific symptom is the error message "perl5db.pl did not return a true value." - to see this message, you should enable the "debugger console" in EPIC Preferences. Furthermore, if you have this problem, debugging doesn't work at all. To fix it, you must edit Cwd.pm of your Perl distribution and remove the offending "eval" keyword from one line, as described in this bug report. DO NOT attempt to fix it by adding Perl's "lib" directory to your project's include path, as this will cause all breakpoints to be ignored!
Perhaps what I've encountered is a defect in ActiveState's version of Perl.
Anyway--after spending way too much time on this--the only way I could get it to work is by replacing
require 'extra\stuff_1.cgi';
with
eval { require 'extra\stuff_1.cgi' };
I dislike having to do this but it's time to move on!
Related
After updating modules in cpan pnp4nagios/NPCD started logging the following in my syslog every time the script was called;
NPCD[19673]: ERROR: Executed command exits with return code '255'
NPCD[19673]: ERROR: Command line was '/etc/pnp4nagios/libexec/process_perfdata.pl -n --bulk /var/spool/icinga2/perfdata/host-perfdata.1524923929'
There didn't appear to be any loss in functionality or data and my graphs where populating as expected - but I was being spammed by this.
Running the script from the cli gave this result;
bash-4.1$ /etc/pnp4nagios/libexec/process_perfdata.pl -n --bulk /var/spool/icinga2/perfdata/host-perfdata.1524919009
tv_interval() 2nd argument should be an array reference at /etc/pnp4nagios/libexec/process_perfdata.pl line 218, <PDFILE> line 111
The only useful google result to that error points at the Time::HiRes module.
It appears that the current version of Time::HiRes was/is the issue. cpan offers Time-HiRes-1.9758 as an update but this appears to be the version causing the issue.
In order to stop the error I had to downgrade that module by doing the following;
make clean in the folder of the installed version (Mine was at .cpan/build/Time-HiRes-1.9758) then fetching the specific version from cpan;
cpan JHI/Time-HiRes-1.9721.tar.gz which installed the older (1.9721) version.
Restarted npcd and the errors where gone.
I'm not sure which version of Time-HiRes introduced this error/change in behaviour as I've not been through them and am not 100% certain where the issue may actually lay (npcd/Time-HiRes/somewhere else). Hopefully this points someone else in the right direction.
From ikegami's comment
"Even in version 1.9721, the second argument (if provided), must be an
array reference. It seems the only change in behaviour is the addition
of input validation. process_perfdata.pl is buggy, and newer
versions of Time::HiRes let you know it."
This is a problem even in the latest version of pnp4nagios.
If you need a quick workaround you can modify the pnp4nagios script process_perfdata.pl so that it does always pass an array reference, as follows (diff output):
sub main {
my $job = shift;
my $t0 = [gettimeofday];
- my $t1;
+ my #t1=();
+ my $t1=\#t1;
my $rt;
my $lines = 0;
# Gearman Worker
I've done this and it seems to work ok and remove the very frequent error message. I'll post back here if it seems to cause issues.
The problem is with the newest library Time:HiRes 1.9758 and the second value from tv_interval bounds. According to manual if ommited, the actual time is used - what is exactly what it does. So you need to apply this command to script process_perfdata.pl:
sed -s 's/tv_interval $t0, $t1/tv_interval $t0/g' -i process_perfdata.pl
After that everything will work as it should.
I experienced the problem with CentOS8 which is not providing older versions of HiRes library. Another symptom is that npcd cannot create .pnp-internal folder.
I'm running into problems testing a new addition to a module. (Specifically - the ~ operator seems to be not working in Math::Complex for this new feature only.) It's too bizarre to be what it appears but the ideal scheme would be to add the -d option on the top line of the .t program.
Well, I was quickly disabused of that idea! It does not invoke the debugger.
If I wanted to use the debugger, I'd need to create an edit of the .t program that:
Uses (the use command) the module directly. not in the form of
BEGIN { use_ok('My::Module') };
Does not "use Test::More;"
A few other edits that cause gluteal pains
The problem with doing that is that any changes I make in the edited test program I still need to transfer back to the true test program use in "make test". Error prone as best.
I am already using "make test TEST_VERBOSE=1" so that my stdio output shows up. But there's GOT to be a simpler way to invoke the debugger on the .t
Thanks for ideas here.
-- JS
use_ok tests are great, but you should have them in test files of their own, not test files that also test other things.
I'm not sure why you would need to avoid Test::More or use_ok to run the debugger, though. What does happen when you try your test directly:
perl -d -Mblib t/yourtestfile.t?
If all else fails, you can try using Enbugger in your test script.
I've had this issue for a while now. Every time I use SOAP::Lite in debug mode (whether normal debugging or with something like NYTProf) it ends up calling the on_fault handler.
I've stepped through and it is due to this error:
Attempt to reload SOAP/Lite/Deserializer/XMLSchema2001.pm aborted.
Compilation failed in require at (eval 1343)[C:\\Perl\\site\\lib/SOAP/Lite.pm:2328] line 3.
...propagated at C:\\Perl\\site\\lib/SOAP/Lite.pm line 2328.
I'm wondering if this is normal and what the best workaround is? Thanks.
Edit: Forgot to mention this is Activestate Perl 5.10.1 on Windows and upgrading is not an option at this time.
Found it! Running perl with both -d and -w flags seems to cause an issue in the debugger with the scope of warnings. It complains about redefined subs in this mode, but ignores them if we supply just one or neither of the -d/-w flags.
The issue is in SOAP::Lite::Deserializer::XMLSchema2001, the BEGIN block maps the as_* methods. dateTime is in the list twice so we get an error about as_dateTime being redefined.
This breaks the initial module compilation, and upon our 2nd attempt produces the error above.
I've got a project written in classic asp, and a particular form's submit is handled by a Perl script.
I'm going to do an enhancement for this project. I installed the latest version of ActivePerl for Windows 32 bits.
I looked at the production environment and saw that in the IIS 7.5, there is an entry on "Handler Mappings" for *.pl to be handled by C:\Perl\bin\PerlEx30.dll. So I did the same thing on development environment. (please note that there is no mapping for "*.cgi" on the Prod. environment)
Now when I'm trying to submit the form which its action is MyScript.pl, I get the following error:
HTTP Error 405.0 - Method Not Allowed
The page you are looking for cannot be displayed because an invalid method (HTTP verb) is being used.
Maybe worth saying that, I'm on 64 bits environment, I tried ActivePerl for Windows 64 bits as well (I mapped *.pl to perl514.dll) but still getting the same error!
Your workaround was to use 32-bit version of perl. If you want to use the 64-bit version, this worked for me on IIS 8.5 Windows 2012 R2:
Add Module Mapping to your site:
Request path: *.pl
Module: CgiModule
Executable: C:\Perl64\bin\perl.exe "%s" %s
Name: Perl CGI
You can test it by creating the following 'hello world' page:
use strict;
use CGI;
my $page = new CGI;
my $msg = "Hello from ActivePerl CGI!";
print $page->header( "text/html" ),$page->start_html( $msg );
print $page->h2($msg);
print $page->end_html;
Name it something like test.pl, drop it into your webroot directory and browse to it to test.
The application pool was set so "Enable 32-Bit Applications = false", I change it to true, and it fixes the issue.
You haven't said whether or not you've gotten ANY Perl to work yet (even a "hello world"), or if the problem is this one particular script (perhaps just on this one particular server).
ANYWAY -
I doubt your Perl install is the problem.
You definitely need to do more troubleshooting.
I'd start with verifying whether a simple, one-line "hello world" will work.
Next, I'd "divide and conquer" to determine exactly WHERE the problem is. I'm guessing it's very probably somewhere in "MyScript.pl". I'm also guessing that it should be fairly easy to track down.
These links might help give you more clues as to exactly what you might look for as you "divide and conquer" (AFTER you've verified that Perl itself can be invoked from your IIS):
What causes an HTTP 405 "invalid method (HTTP verb)" error when POSTing a form to PHP on IIS?
http://www.tech-faq.com/troubleshooting-iis.html
PS:
I'm guessing the problem might be as simple as a missing, or inappropriate, URL in "MyScript.pl"!
PPS:
At the risk of repeating myself - please verify "helo_world.pl" first. If it doesn't work, please post the complete "hello_world" script and the complete error message(s).
First time perl user and I am trying to debug some script to follow project logic and of course syntax.
Using cygwin after entering at command line $
$ perl -d sample.pl
Loading DB routines from perl5db.pl version 1.3
Editor support available.
Enter h or `h h' for help, or `perldoc perldebug' for more help.
main::(sample.pl:5): print 'Hello world.'; # Print a message
DB<1>
It hangs at the DB<1> line. I cannot enter anything at the prompt.
Is there a reason why this post is inappropriate? or how is this not clear?
This is the actual program code:
#!/usr/local/bin/perl
#
# Program to do the obvious
#
print 'Hello world.'; # Print a message
I upgraded my cygwin installation at home and ran into a similar problem (though maybe not the exact same problem -- the perl debugger still responds to my input but does not display my input, and fubars my input even after I quit the debugger). In the meantime while I figure what is going on, my workaround is to fire up xemacs, launch a shell (M-x shell), and run the perl debugger from the emacs buffer.
If this works for you, then there is something funky going on with your cygwin terminal settings. If your debugger hangs even in an emacs buffer, then something else funky is going on but I have no idea what it could be.
Sorry for reviving this three-year-old question, but I believe to have been hit with the same problem, and to have found the solution.
In my case, perl -de0 invokes infocmp from ncurses, which hangs in a weird way (can't kill it). And infocmp seemed to be a victim of my Avast anti-virus which is listed under BLODA as affecting Cygwin. Disabling it resolved the issue -- see if you have any of the listed applications and try disabling it (perhaps also try safe mode).
Also, simply renaming infocmp.exe allowed perl -d to run normally. In the end I used this approach and left my Avast running.
It could also be a different executable that perl -d is starting -- try to run whatever hangs with strace, see what is the last executable mentioned and try to see if that is the culprit.