Perl cgi compilation error in autovivication.pm

Question

I'm using a perl cgi script that uses our own libraries, which use the "no autovivification" pragma. E.g.

/usr/lib/company/mysim.cgi:

#!/usr/bin/perl -w

use strict;
# ... other use
use Company::Module1;

/usr/lib/perl5/Company/Module1.pm

package Company::Module1;

no autovivification;
use strict;
use warnings;

Approximately 50% of the time, when accessing the URL to reach the cgi script the compilation fails with...

[Fri Dec 04 15:40:10.744901 2015] [:error] [pid 30455:tid 2961136448] Bareword "A_HINT_STRICT" not allowed while "strict subs" in use at /usr/lib/i386-linux-gnu/perl5/5.20/autovivification.pm line 144.\nBareword "A_HINT_WARN" not allowed while "strict subs" in use at /usr/lib/i386-linux-gnu/perl5/5.20/autovivification.pm line 144.\nBareword "A_HINT_FETCH" not allowed while "strict subs" in use at /usr/lib/i386-linux-gnu/perl5/5.20/autovivification.pm line 144.\nBareword "A_HINT_STORE" not allowed while "strict subs" in use at /usr/lib/i386-linux-gnu/perl5/5.20/autovivification.pm line 144.\nBareword "A_HINT_EXISTS" not allowed while "strict subs" in use at /usr/lib/i386-linux-gnu/perl5/5.20/autovivification.pm line 144.\nBareword "A_HINT_DELETE" not allowed while "strict subs" in use at /usr/lib/i386-linux-gnu/perl5/5.20/autovivification.pm line 144.\nCompilation failed in require at /usr/lib/company/mysim.cgi line 14.\nBEGIN failed--compilation aborted at /usr/lib/company/mysim.cgi line 14.\n

(taken from /var/log/apache2/ssl/error.log as this script sits on the https port).

My environment is: - debian jessie (8.2) - tomcat7 - apache2 (2.4) - perl 5.20.2 - libautovivification-perl 0.12-1+b1

My questions are:

Has anyone seen this before? It seems odd that the autovivification module fails to compile due to a "use strict" pragma.
Can anyone explain the intermittent nature of the compilation error? Even more odd, the cgi fails to compile ~half the time, and works fine (i.e. runs and returns expected results) the other ~half.

Thanks for your time.

09/12/2015: Some additional information...

Thanks all for the feedback.

There's no explicit creation of threads, though this is in the context of apache so there's presumably threading of requests.

The root cause does seem to be a failure in the XSLoader. At least this minimal working example...

package autovivification;

use 5.008_003;

use strict;
use warnings;

our $VERSION;
BEGIN {
 $VERSION = '0.12';
}

BEGIN {
 require XSLoader;
 XSLoader::load(__PACKAGE__, $VERSION);
}

my %bits = (
 strict => A_HINT_STRICT,
 warn   => A_HINT_WARN,
 fetch  => A_HINT_FETCH,
 store  => A_HINT_STORE,
 exists => A_HINT_EXISTS,
 delete => A_HINT_DELETE,
);

compiles, whereas this

package autovivification;

use 5.008_003;

use strict;
use warnings;

our $VERSION;
BEGIN {
 $VERSION = '0.12';
}

#BEGIN {
# require XSLoader;
# XSLoader::load(__PACKAGE__, $VERSION);
#}

my %bits = (
 strict => A_HINT_STRICT,
 warn   => A_HINT_WARN,
 fetch  => A_HINT_FETCH,
 store  => A_HINT_STORE,
 exists => A_HINT_EXISTS,
 delete => A_HINT_DELETE,
);

fails with the same error.

So, I'll go a-poking around for a load error in the apache logs.... somewhere.

Thanks again for your time.

16/12/2015: Update - Fixed

The root cause was mod_perl, combined with a (possible) change between apache 2.2 and 2.4. The apache configuration for the script, which gives it a ScriptAlias URI of /cgi-bin/script, occurs before setting up the URI /cgi-bin to be handled by mod_perl. In apache 2.2, this ordering seems to be important and the script was not handled by mod_perl. However, in apache 2.4 the ordering does not seem to be important and the script is now handled by mod_perl.

The error arose because this script was not (and never meant to be) handled by mod_perl. The fix was to change the URI for the script to /somethingelse/script.

Thanks to everyone for the comments.

A_HINT_STRICT, A_HINT_WARN, etc. are macros defined in XS code. Do you get any other errors related to XSLoader::load failing or something like that? — ThisSuitIsBlackNot
They are actually Perl subs created by the XS module when it's loaded. (newCONSTSUB(stash, "A_HINT_STRICT", newSVuv(A_HINT_STRICT));, called from the BOOT section.) — ikegami
This is really weird since the module shouldn't load at all if the XS component doesn't load. Does your script create threads? — ikegami
I see you fixed your issue, but I'm curious as to the exact cause. Can you please edit the relevant bits of your Apache configuration into the question, especially the mod_perl bits? I can run a simple script with mod_perl that does use autovivification; without errors. It would be nice to know the exact cause in case anybody in the future has the same issue. — ThisSuitIsBlackNot
I'm not sure what else I can add. In our migration from Debian Wheezy (apache 2.2) to Debian Jessie (apache 2.4) we came across this issue a few times and in each case it was because the perl script was not "mod_perl" safe and the fix was to tweak the configuration to ensure the perl handler was "cgi-script" and not "mod_perl". — HalfOpenedEye

Unknown Unknown · Accepted Answer · 2017-08-16T11:37:09

The root cause was mod_perl, combined with a (possible) change between apache 2.2 and 2.4. The apache configuration for the script, which gives it a ScriptAlias URI of /cgi-bin/script, occurs before setting up the URI /cgi-bin to be handled by mod_perl. In apache 2.2, this ordering seems to be important and the script was not handled by mod_perl. However, in apache 2.4 the ordering does not seem to be important and the script is now handled by mod_perl.

The error arose because this script was not (and never meant to be) handled by mod_perl. The fix was to change the URI for the script to /somethingelse/script. – HalfOpenedEye

Perl cgi compilation error in autovivication.pm

1 Answers