Front page | perl.perl5.porters |
Postings from June 2014
Re: [rt.cpan.org #96596] Incorrect use of apply causes sort tosegfault in XS
Thread Previous
|
Thread Next
From:
Dave Mitchell
Date:
June 23, 2014 15:01
Subject:
Re: [rt.cpan.org #96596] Incorrect use of apply causes sort tosegfault in XS
Message ID:
20140623150136.GR15468@iabyn.com
On Mon, Jun 23, 2014 at 12:47:12PM +0200, Jens Rehsack wrote:
>
> Am 23.06.2014 um 12:39 schrieb Dave Mitchell <davem@iabyn.com>:
>
> > On Sun, Jun 22, 2014 at 11:13:47AM -0600, Karl Williamson wrote:
> >> I confirmed that it fails in blead, and it fails here (I have no expertise
> >> about this area of Perl):
> >>
> >> § valgrind /home/khw/cpanbroken/bin/perl -Mblib -MList::MoreUtils=apply -le
> >> '@a = sort apply 1,2'
> >> ==23028== Memcheck, a memory error detector
> >> ==23028==
> >> ==23028== Invalid read of size 8
> >> ==23028== at 0x11DC7A1A: XS_List__MoreUtils_apply (MoreUtils.xs:595)
> >> ==23028== by 0x6FFF77: S_sortcv_xsub (pp_sort.c:1891)
> >> ==23028== by 0x6F9865: dynprep (pp_sort.c:197)
> >> ==23028== by 0x6F9CFC: S_mergesortsv (pp_sort.c:381)
> >> ==23028== by 0x6FC17A: Perl_sortsv_flags (pp_sort.c:1469)
> >> ==23028== by 0x6FE863: Perl_pp_sort (pp_sort.c:1705)
> >> ==23028== by 0x537698: Perl_runops_debug (dump.c:2370)
> >> ==23028== by 0x457C9C: S_run_body (perl.c:2411)
> >> ==23028== by 0x4572CD: perl_run (perl.c:2333)
> >> ==23028== by 0x41D354: main (perlmain.c:114)
> >> ==23028== Address 0x0 is not stack'd, malloc'd or (recently) free'd
> >>
> >> The lines in MoreUtils.xs are:
> >> 594 cv = sv_2cv(code, &stash, &gv, 0);
> >> 595 PUSH_MULTICALL(cv);
> >>
> >> If this still looks like a Perl bug to you, please file a ticket using
> >> perlbug
> >
> > It's an LMU bug. It assumes that the prototype is sufficient to make the
> > first arg always be passed as a CV, but there are ways in perl to bypass
> > this. One way we have already seen is to use the function as an arg to
> > sort; another way would be:
> >
> > $ perl5200 -Mblib -MList::MoreUtils=apply -e '@_=(1,2); &apply'
> > Segmentation fault (core dumped)
>
> Wait a minute: Original report didn't use the non-prototype check call, he
> used "sort apply 1,2"
I understand that. I was merely demonstrating that in some circumstances,
perl will legitimately bypass prototype checks when calling a function;
so an XS function cannot rely on its args having been pre-checked.
There is the related issue of whether it is correct for sort to invoke a
function without first processing its prototype.
> and while 5.14.2 approved the prototype correctly,
> 5.15.5 didn't do that.
I don't understand what you are referring to here. In neither 5.14.2 nor
5.16.0 (the two I just checked) does sort do prototype checking:
$ perl5142 -we'sub f($$$$) { 1 } f(1,2);'
Not enough arguments for main::f at -e line 1, near "2)"
Execution of -e aborted due to compilation errors.
$ perl5142 -we'sub f($$$$) { 1 } @a = sort f "abc", "def";'
$ perl5160 -we'sub f($$$$) { 1 } @a = sort f "abc", "def";'
$
> That explicit unchecked calls can behave unexpected might or might not be
> intensional.
It's intentional for the &f; form; its debatable for the sort variant.
> To be true: when each sub has to do a parameter validation, entire prototype
> check is insane. With my recent pushed fix, it's not possible to bypass the
> validation of the code-block anymore - which definitively behaves different
> than former versions. And when one fine day a callable type is introduced
> which is neither SVt_PVCV nor "&{}" overloaded, LMU will reject calling it.
Sorry, but I didn't understand any part of that paragraph...
> I rate that as a bug in Perl!
.. so I am unable to comment yet on that line.
--
Please note that ash-trays are provided for the use of smokers,
whereas the floor is provided for the use of all patrons.
-- Bill Royston
Thread Previous
|
Thread Next