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.
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 decided my birthday would be a good time to try and fix my Lisp problems.
I've received a Lisp program from someone to run an experiment. It works well on his OS X environment. However, I can't get it to run on either Windows 7 or Ubuntu. The program uses Act-R 6.2 to run a model. When I try to load the .lisp file I receive the following error:
:Reader error on #<BASIC-FILE-CHARACTER-INPUT-STREAM ("*path*"/28 UTF-8)#xCFAD1AE, near position 1048, within "smile* (#initWithCo":
Undefined character #\/ in a #\# dispatch macro.
While executing: CCL:SIGNAL-READER-ERROR, in process listener(1)
The error is the exact same for Windows 7 and Ubuntu. Here is the console output if it is required:
http://i.stack.imgur.com/dFXVm.png
It seems load-turing-application.lisp loads multiple other files, one of which is turing-application-v1.lisp, in which the line (setf *smile* (#/initWithContentsOfFile: (#/alloc ns:ns-image)(ccl::%make-nsstring "smiley.jpg")))
seems to be the culprit. I suspect it has something to do with the #/-notation.
Any ideas would be appreciated.
This is answered in the comments, but #/ is a CCL syntax that only is available on OS X. This code is not expected to work on linux or windows.
We have a custom perl install (5.10.1) in /usr/share, and I tried to do a 'cpan -i' install of GeoIP2 here
After doing this, it seemed to install a lot of dependencies I couldn't keep track of, and since I've been getting an error
Subroutine IO::Socket::INET6::sockaddr_in6 redefined at /usr/share/perl5/Exporter.pm line 67
On most scripts that we run that uses a 'use' command. I've been trying to nail down which module eventually calls that, but not succeeded as yet.
After some research, one suggestion was to comment out the following lines of
/usr/share/perl5/IO/Socket/INET6.pm # (version 2.56, think latest is 2.72)
###commented out the following
###use Socket6 (
### qw(AI_PASSIVE inet_ntop inet_pton getaddrinfo
### sockaddr_in6 unpack_sockaddr_in6_all pack_sockaddr_in6_all)
###);
This has stopped the errors from appearing on various scripts. Does anyone know if this is safe to do (ie will it cause further problems later), and is there a better way to go (ie is it possible to just update that module, I'm guessing that would cause problems and break other stuff?). What would be the best method of getting the module updated correctly ?
This was a bug in IO::Socket::INET6 which was fixed in version 2.69 according to this bug report:
Subroutine main::sockaddr_in6 redefined at /usr/share/perl/5.14/Exporter.pm line 67.
...
Should be fixed in 2.69.
You can update the module using cpan with the command cpan IO::Socket::INET6 from the shell as root.
Easiest is just to stop using IO::Socket::INET6 at all. That was created a very long time ago, but a far better solution has been created using the core Socket module, being IO::Socket::IP. Furthermore, this latter module is now core also since the newly-released 5.20. it would be better to use that IO::Socket::IP as that is the new core-recommended way to achieve IPv4/IPv6 transparency from now on.
I am using Perl in Eclipse.
In the same directory, I have a .pl file and two .pm files (pmFile1.pm, pmFile2.pm).
At the top of the .pl file, I use the command:
use pmFile1;
use pmFile2;
I get an error
Compilation failed in require
I do not believe I had this error earlier. I have researched this error online, and cannot figure out what may have caused it, because I have not found a similar situation to mine that caused the error. I do not know what other information would be pertinent to include, but will add anything if asked...
Thank you.
I suggest you check the module pmFile1.pm for errors in a terminal shell
$ perl -c pmFile1.pm
syntax error at pmFile1.pm line 1, near "."
pmFile1.pm had compilation errors.
When entering a single dot . as a syntax error into pmFile1.pm and running the p.pl file then the errors below are shown in Eclipse, the same as you described. If you run the .pl file in a terminal shell then you get the same compilation failed in require as in eclipse:
$ perl p.pl
syntax error at pmFile1.pm line 1, near "."
Compilation failed in require at p.pl line 1.
BEGIN failed--compilation aborted at p.pl line 1.
This may not be your problem, but I've been "bitten" by something similar before: check the End of Line chars in the file. It may be that your code is seen by the compiler to be all one line, making an error anywhere in the code appear as being on line 1 when visually (in the editor) the offending line would be later in the code. In notepad++ you resolve this sort of issue by using the Edit > EOL Conversion > Windows Format (or whatever format is correct for you) menu option, though other editors will likely have a similar feature for *NIX <-> Windows EOL conversions. This error would make sense if you can successfully use the module files giving you an error without errors in other script files.
I solved this by changing the required package to some dummy name, then retaining it.
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!