Bug #75443 for Filter-Crypto: Unexpected "Can't run with Perl compiler backend at …"

Wed Feb 29 23:15:36 2012 dgahring [...] mac.com - Ticket created

Subject:	Unexpected "Can't run with Perl compiler backend at …"
Date:	Wed, 29 Feb 2012 23:15:23 -0500
To:	bug-Filter-Crypto [...] rt.cpan.org
From:	Gahring David <dgahring [...] mac.com>

Greetings, I have an application that uses Filter::Crypto to encrypt the source code. I recently upgraded my Perl environment to 5.14.2, and when I attempt to run an encrypted object using the newly built Perl, it fails with the following: Can't run with Perl compiler backend at /opx/perl/lib/5.14.2/XSLoader.pm line 95. BEGIN failed--compilation aborted at /opx/perl/lib/site_perl/5.14.2/sun4-solaris-thread-multi/Filter/Crypto/Decrypt.pm line 37. Compilation failed in require at /opx/perl/lib/site_perl/OPXutils.pm line 1. BEGIN failed--compilation aborted at /opx/perl/lib/site_perl/OPXutils.pm line 1. Compilation failed in require at /opx/cver/sbin/opxjp line 19. BEGIN failed--compilation aborted at /opx/cver/sbin/opxjp line 19. After doing some digging, I found some code in the Decrypt.xs source that appears to be checking to ensure that we aren't running a Perl compiler backend with the following check.. if (gv_stashpvn("B", 1, FALSE)) croak("Can't run with Perl compiler backend"); I do not believe I am running a backend, so the only way around this issue was to comment out these lines of code. This seemed like using a sledgehammer to fix the problem, but I was at a loss as to what other options I had. I guess my first question is whether this is actually a bug, or am I missing something obvious? Please advise. Here is the standard stuff that may be helpful: [version of Filter::Crypto] 1.33 [output of perl -V] sal-/opx/logs> opxv200perl -V Summary of my perl5 (revision 5 version 14 subversion 2) configuration: Platform: osname=solaris, osvers=2.10, archname=sun4-solaris-thread-multi uname='sunos sal 5.10 generic_144488-17 sun4u sparc sunw,sun-fire-v445 ' config_args='-de -Dcc=gcc -Dprefix=/opx/perl -Dusethreads' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV', optimize='-O', cppflags='-D_REENTRANT -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.4.6', gccosandvers='solaris2.10' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib ' libpth=/usr/local/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lpthread -lc perllibs=-lsocket -lnsl -ldl -lm -lpthread -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_USE_SAFE_PUTENV USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API Built under solaris Compiled at Feb 27 2012 21:39:30 @INC: /opx/perl/lib/site_perl/5.14.2/sun4-solaris-thread-multi /opx/perl/lib/site_perl/5.14.2 /opx/perl/lib/5.14.2/sun4-solaris-thread-multi /opx/perl/lib/5.14.2 /opx/perl/lib/site_perl . [output of uname -a] SunOS sal 5.10 Generic_144488-17 sun4u sparc SUNW,Sun-Fire-V445 Thanks! Dave

Thu Mar 01 17:31:35 2012 shay [...] cpan.org - Correspondence added

On Wed Feb 29 23:15:36 2012, dgahring@mac.com wrote: Show quoted text

> Greetings, > > I have an application that uses Filter::Crypto to encrypt the source > code. I recently upgraded my Perl environment to 5.14.2, and when > I attempt to run an encrypted object using the newly built Perl, it > fails with the following: > > Can't run with Perl compiler backend at

[...] Show quoted text

> > After doing some digging, I found some code in the Decrypt.xs source > that appears to be checking to ensure that we aren't running a Perl > compiler backend with the following check.. > > if (gv_stashpvn("B", 1, FALSE)) > croak("Can't run with Perl compiler backend"); > > I do not believe I am running a backend, so the only way around this > issue was to comment out these lines of code. This seemed like > using a sledgehammer to fix the problem, but I was at a loss as to > what other options I had. > > I guess my first question is whether this is actually a bug, or am I > missing something obvious? Please advise. > > Here is the standard stuff that may be helpful: > > [version of Filter::Crypto] > > 1.33 >

Thanks for the report. I recently encountered this issue using 5.14.x, and found that the problem was in the Carp module, which was auto-vivifying the B:: stash, which made Filter-Crypto think that the compiler backend was loaded when it wasn't really. The issue of Carp auto-vivifying the B:: stash was fixed in Carp 1.21 (see http://perl5.git.perl.org/perl.git/commit/1a6d530815). I've just released Filter-Crypto-1.33 (which I see you're using already) with a check in the PAR::Filter::Crypto module that a faulty Carp module is not in use because the PAR-extraction/execution code loads the Carp module and can therefore cause breakage. However, I completely missed the point that any source files encrypted with Filter-Crypto (but not even packaged using PAR!) will have the same problem if they use the Carp module themselves. I strongly suspect that your code is including the Carp module, either directly or indirectly, and therefore falling foul of this issue, given that you're using perl 5.14.2, which contains Carp 1.20. I will roll a new version of Filter-Crypto soon with a solution for this problem, but in the meantime you can fix it by simply upgrading to a more recent version of Carp: it was recently "dual-lived", so it is now available separately from CPAN. Anything from version 1.21 onwards should work fine. Steve

Thu Mar 01 17:31:36 2012 The RT System itself - Status changed from 'new' to 'open'

Fri Mar 02 16:29:26 2012 dgahring [...] mac.com - Correspondence added

Subject:	Re: [rt.cpan.org #75443] Unexpected "Can't run with Perl compiler backend at …"
Date:	Fri, 02 Mar 2012 16:29:13 -0500
To:	bug-Filter-Crypto [...] rt.cpan.org
From:	Gahring David <dgahring [...] mac.com>

Hi Steve, After reading your reply, I've pulled down and installed the latest Carp, then reinstalled a fresh Filter::Crypto. Everything seems to work fine now with the new Carp in place. I admit that I did see another bug related to Carp earlier, but I didn't think it was related to the compiler backend. I guess I could have tried Carp anyway, but at least this way you know about it too. :-) btw.. Thanks for a GREAT tool, regardless of the "religious" nerve it seems to touch in some.. lol Regards, Dave

Fri Mar 02 17:09:49 2012 shay [...] cpan.org - Correspondence added

On Fri Mar 02 16:29:26 2012, dgahring@mac.com wrote: Show quoted text

> Hi Steve, > > After reading your reply, I've pulled down and installed the latest > Carp, then reinstalled a fresh Filter::Crypto. Everything seems to > work fine now with the new Carp in place. > > I admit that I did see another bug related to Carp earlier, but I > didn't think it was related to the compiler backend. I guess I could > have tried Carp anyway, but at least this way you know about it too. > :-) > > btw.. Thanks for a GREAT tool, regardless of the "religious" nerve it > seems to touch in some.. lol > > Regards, > > Dave >

Glad to hear it's working for you now. I've just this minute uploaded a new version (1.34) which works around the problem with older Carps by looking just a tiny bit harder to see if B really is loaded, but obviously there is no harm in your having the latest Carp now anyway. I'm closing this ticket now, so please don't reply any more on it otherwise it'll get re-opened! :-) Thanks again for the report. Steve

Fri Mar 02 17:10:20 2012 shay [...] cpan.org - Status changed from 'open' to 'resolved'

Sun Mar 15 12:22:24 2015 The RT System itself - Status changed from 'resolved' to 'open'

Thu Jan 07 16:47:18 2016 shay [...] cpan.org - Correspondence added

Marking this ticket as "resolved" again, after the RT System itself mysteriously re-opened it!

Thu Jan 07 16:47:19 2016 shay [...] cpan.org - Status changed from 'open' to 'resolved'