New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invalid handshake, static build, 5.21.6+, 32bit Linux, no threads, no debug #14624
Comments
From zzgrim@gmail.comFor a perl built statically with the aid of Marc Lehmann's staticperl $ ./perl -MDigest::xxHash -E1 This is a problem that appeared between 5.21.5 and 5.21.6 and still exists in 5.21.10. I made a repo for easier reproducible builds on a few different VMs. https://github.com/zgrim/perlbug-handshake.git eg: Build flags are specified in .staticperlrc. HTH Perl Info
|
From @doughera88On Sat, Mar 28, 2015 at 07:47:21AM -0700, zgrim wrote:
Could you please include the output of ./perl -V in the directory where that test fails? (the perlbug output included Thanks, -- |
The RT System itself - Status changed from 'new' to 'open' |
From @bulk88On Sat Mar 28 07:47:21 2015, zzgrim@gmail.com wrote:
"(got handshake key 0x7bc0000, needed 0x7cc0000)" means in your XS module, the definition of the perl's master interpreter struct is smaller than the interp engine expects (XS module says its 0x7bc bytes long, interp core says its 0x7cc bytes long). The layouts of the structs are not compatible. They must be the same otherwise memory corruption occurs. This is probably not a bug in Perl but in your non p5p-code. The error message means that a .so or .o, is not being executed by the same perl (same config.h, same -Ds on cmd line, same Config.pm, same perl 5.X._, where X must match) it was compiled against. If it worked in the past, you were lucky it didn't SEGV. Unlike with pure Perl modules, you can not copy paste XS module .so'es between different perl builds instead of rebuilding them from source (with the 1 small exception of perl maintenance releases, aslong as they have an identical input to Configure/config.h/Config.pm). Briefly looking at your repo, https://github.com/zgrim/perlbug-handshake/blob/master/staticperl has # perl build variables but https://github.com/zgrim/perlbug-handshake/blob/master/.staticperlrc which shows a different perl build BUILD_DEFAULT="5.21.10" 2 different perls with different -Ds. I dont use unix or unix shell lang or the staticperl script, and this ticket is beyond my knowledge, but I am the author of that error message. I got sick of getting SEGVs when I switch which version of perl interp is in my PATH, and forget to do "make clean/perl Makefile.PL/make test" and instead just do "make test" and it instantly SEGVs in the XS module I am working on. Also when I upgrade my blead perl, I dont delete everything out of lazyness, I would much rather get error messages saying things are out of sync and to rebuild the XS module rather than a meaningless (without C debugger) SEGV. -- |
From @bulk88On Sat Mar 28 22:38:13 2015, bulk88 wrote:
Your repo also has https://github.com/zgrim/perlbug-handshake/blob/master/ext/Digest-xxHash-1.02/Makefile.PL Digest::xxHash on CPAN does not have a Makefile.PL, and is Module::Build based (has Build.PL, there is no Makefile.PL) https://metacpan.org/source/SANKO/Digest-xxHash-1.02 . Inside this custom Makefile.PL I see #! perl the "CCFLAGS => '-Isrc'," wipes all the -Ds. You have to normally append to CCFLAGS, not replace it and throw away all the -Ds that used to be in it. -- |
From zzgrim@gmail.comOn 2015-03-29 01:19:51 -0700, bulk88 via RT wrote:
Hello. CCFLAGS => $Config{ccflags}, makes the issue go away. The reason I had to do a custom Makefile.PL with ExtUtils::MakeMaker is that I was I've been using this whole "static" setup for 4+ years, makes mass deployments But i have to say, although raising the handshake exception seems like a good Another side-effect is that lazily required XS code statically built with Could the enforcement be toggled at compile-time ? |
From @bulk88On Sun Mar 29 20:07:49 2015, zzgrim@gmail.com wrote:
You can't mix XS modules (.so/.dll/.o files) between different perl versions or build configs except for maint releases of perl. What dohappens when perl interp thinks a scalar's floating point number is 8 bytes long, and an XS module thinks it is 10 bytes long (long double build)? If it worked before, it was by chance you didn't run any XS code where the meaning of bits in a bitfield changed enough for it to be observable with side effects. Also since Perl 5.13.4 (basically 5.14.0), perl version numbers were checks to make sure they match between XS modules and the interp. Handshake code extends that compatibility check even further. If you are using the same .so or .o files between different interps how did you deal with "Perl API version %s of %s does not match %s" failures from 5.14 to 5.20? The handshake check is done once, only when you use/require an XS module. I dont think loading an XS module is a rare thing to happen. Grep your private code base for every use()/require() line and write a test that use()/require()s every XS module in your software stack. That way you find out if you have handshake failures or not before a lazy loaded module is require()ed in a rare PP branch.
You are choosing the quick and wrong way to fix the problem. Perl is open source software, nobody can stop you from removing the handshake checks from perl interp's C code in util.c, but if you do that, it is very wrong to later ask for support on why perl is SEGVing or causing "panic:" errors or unreproducible on other systems bugs. I think this bug is heading towards close or rejected, there is nothing for p5p to change here. -- |
From @jkeenanOn Wed, 05 Aug 2015 23:23:39 GMT, bulk88 wrote:
Since there has been no further discussion in this RT in a year-and-a-half, I will implement bulk88's suggestion and close this ticket. -- |
@jkeenan - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#124201 (status was 'rejected')
Searchable as RT124201$
The text was updated successfully, but these errors were encountered: