Skip Menu |
Report information
Id: 133142
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: randir <sergey.aleynikov [at] gmail.com>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: core
Perl Version: 5.27.9
Fixed In: (no value)



To: perlbug [...] perl.org
From: Sergey Aleynikov <sergey.aleynikov [...] gmail.com>
Subject: Bleadperl breaks Devel::FindRef
Date: Mon, 23 Apr 2018 14:52:17 +0300
Download (untitled) / with headers
text/plain 4.2k
This is a bug report for perl from sergey.aleynikov@gmail.com, generated with the help of perlbug 1.41 running under perl 5.27.9. ----------------------------------------------------------------- [Please describe your issue here] commit eacbb37937698a035d5ed63fcbdf15dd4eab56cf Author: Daniel Dragan <bulk88@hotmail.com> Date: Fri Oct 31 03:23:17 2014 -0400 free up CvPADLIST slot for XSUBs for future use broke Devel::FindRef for perls compiled with -DDEBUGGING with the following assertion failure: perl: FindRef.xs:180: XS_Devel__FindRef_find_: Assertion `!(((XPVCV*)({ void *_p = (((CV*)(sv))->sv_any); _p; }))->xcv_flags & 0x0008)' failed. While a patch for Devel::FindRef is quite trivial, I'd like to know, are there any plans for CvPADLIST slots in XSUBs? Or isn't this assertion obsolete now? [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=low --- Site configuration information for perl 5.27.9: Configured by dur-randir at Wed Jan 31 10:14:37 MSK 2018. Summary of my perl5 (revision 5 version 27 subversion 9) configuration: Commit id: 577d3e04be845580196418dd9df1575e2cb4c0b6 Platform: osname=darwin osvers=13.4.0 archname=darwin-2level uname='darwin isengard.local 13.4.0 darwin kernel version 13.4.0: mon jan 11 18:17:34 pst 2016; root:xnu-2422.115.15~1release_x86_64 x86_64 ' config_args='-de -Dusedevel' hint=recommended useposix=true d_sigaction=define useithreads=undef usemultiplicity=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='cc' ccflags ='-fno-common -DPERL_DARWIN -mmacosx-version-min=10.9 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -DPERL_USE_SAFE_PUTENV' optimize='-O3' cppflags='-fno-common -DPERL_DARWIN -mmacosx-version-min=10.9 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='' gccversion='4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long' ivsize=8 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='cc' ldflags =' -mmacosx-version-min=10.9 -fstack-protector -L/usr/local/lib' libpth=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib /usr/local/lib /usr/lib libs=-lpthread -lgdbm -ldbm -ldl -lm -lutil -lc perllibs=-lpthread -ldl -lm -lutil -lc libc= so=dylib useshrplib=false libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=bundle d_dlsymun=undef ccdlflags=' ' cccdlflags=' ' lddlflags=' -mmacosx-version-min=10.9 -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector' --- @INC for perl 5.27.9: lib /usr/local/lib/perl5/site_perl/5.27.9/darwin-2level /usr/local/lib/perl5/site_perl/5.27.9 /usr/local/lib/perl5/5.27.9/darwin-2level /usr/local/lib/perl5/5.27.9 --- Environment for perl 5.27.9: DYLD_LIBRARY_PATH (unset) HOME=/Users/dur-randir LANG=en_US.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/Users/dur-randir/perlbrew/bin:/Users/dur-randir/perlbrew/perls/perl-5.22.1/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/texbin PERLBREW_BASHRC_VERSION=0.80 PERLBREW_HOME=/Users/dur-randir/.perlbrew PERLBREW_MANPATH=/Users/dur-randir/perlbrew/perls/perl-5.22.1/man PERLBREW_PATH=/Users/dur-randir/perlbrew/bin:/Users/dur-randir/perlbrew/perls/perl-5.22.1/bin PERLBREW_PERL=perl-5.22.1 PERLBREW_ROOT=/Users/dur-randir/perlbrew PERLBREW_VERSION=0.80 PERL_BADLANG (unset) SHELL=/usr/local/bin/zsh
Date: Wed, 25 Apr 2018 11:56:19 +0100
From: Dave Mitchell <davem [...] iabyn.com>
CC: bulk88 <bulk88 [...] hotmail.com>
Subject: Re: [perl #133142] Bleadperl breaks Devel::FindRef
To: perl5-porters [...] perl.org
On Mon, Apr 23, 2018 at 04:52:26AM -0700, Sergey Aleynikov wrote: Show quoted text
> commit eacbb37937698a035d5ed63fcbdf15dd4eab56cf > Author: Daniel Dragan <bulk88@hotmail.com> > Date: Fri Oct 31 03:23:17 2014 -0400 > > free up CvPADLIST slot for XSUBs for future use > > broke Devel::FindRef for perls compiled with -DDEBUGGING with the > following assertion failure: > > perl: FindRef.xs:180: XS_Devel__FindRef_find_: Assertion > `!(((XPVCV*)({ void *_p = (((CV*)(sv))->sv_any); _p; }))->xcv_flags & > 0x0008)' failed. > > While a patch for Devel::FindRef is quite trivial, I'd like to know, > are there any plans for CvPADLIST slots in XSUBs? Or isn't this > assertion obsolete now?
I think Daniel would have to be the one to answer that question, but in general, freeing up a slot in CV for potential future new uses seems like a Good Thing, and so the assertion isn't obsolete. (Since this change was in 5.22.0, I'm removing this ticket from the 5.28 blockers list.) -- In England there is a special word which means the last sunshine of the summer. That word is "spring".
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.5k
On Wed, 25 Apr 2018 03:56:42 -0700, davem wrote: Show quoted text
> On Mon, Apr 23, 2018 at 04:52:26AM -0700, Sergey Aleynikov wrote:
> > commit eacbb37937698a035d5ed63fcbdf15dd4eab56cf > > Author: Daniel Dragan <bulk88@hotmail.com> > > Date: Fri Oct 31 03:23:17 2014 -0400 > > > > free up CvPADLIST slot for XSUBs for future use > > > > broke Devel::FindRef for perls compiled with -DDEBUGGING with the > > following assertion failure: > > > > perl: FindRef.xs:180: XS_Devel__FindRef_find_: Assertion > > `!(((XPVCV*)({ void *_p = (((CV*)(sv))->sv_any); _p; }))->xcv_flags & > > 0x0008)' failed. > > > > While a patch for Devel::FindRef is quite trivial, I'd like to know, > > are there any plans for CvPADLIST slots in XSUBs? Or isn't this > > assertion obsolete now?
> > I think Daniel would have to be the one to answer that question, > but in general, freeing up a slot in CV for potential future new uses > seems like a Good Thing, and so the assertion isn't obsolete. > > (Since this change was in 5.22.0, I'm removing this ticket from the 5.28 > blockers list.)
The assertion stops XS code from reading the "padlist" of an XSUB. There is no legitimate reason to read the "padlist" of an XSUB since XSUBs dont have any and the proc will probably SEGV. The padlist slot in XSUBs is used on unthreaded perl to pass a magic unique value that must round trip from the caller (IE libperl) of the XSUB, through the XSUB and back into libperl. This stops a scenario where an XS SO/DLL compiled against another perl version, is loaded by one perl (a PATH/CWD/PERL5DB/PERL5LIB/sitecustomize/@INC/didnt delete "site/lib/auto" dir when upgrading perl/copy paste XS binaries mistake), and that XS SO/DLL then loads its original compiled against libperl into the process, and takes data structs from the caller libperl and passes them to the second libperl and there is a SEGV inside the 2nd libperl. Fixing Devel::FindRef is very easy. I did see the assert failure. But it was easy to fix. case SVt_PVCV: { if(!CvISXSUB(sv)){<<<<<<<<<<<ADDD THIS PADLIST *padlist = CvPADLIST (sv); if (padlist) and add a matching "}" after the end of "if (padlist)"'s "}". This is more crude but also works. case SVt_PVCV: { PADLIST *padlist = CvISXSUB(sv) ? NULL : CvPADLIST (sv); if (padlist) -- bulk88 ~ bulk88 at hotmail.com


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org