Skip Menu |

This queue is for tickets about the Want CPAN distribution.

Report information
The Basics
Id: 94086
Status: resolved
Priority: 0/
Queue: Want

People
Owner: Nobody in particular
Requestors: zefram [...] fysh.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: panic on 5.19.10
Date: Fri, 21 Mar 2014 14:29:50 +0000
To: bug-Want [...] rt.cpan.org
From: Zefram <zefram [...] fysh.org>
On Perl 5.19.10: $ make test PERL_DL_NONLAZY=1 /opt/perl-5.19.10/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/all.t ....... 1/70 Want panicked: Unexpected op in slice (null) t/all.t ....... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 22/70 subtests t/assign.t .... ok t/boolean.t ... ok t/damian.t .... ok t/err.t ....... ok t/methcall.t .. ok t/object.t .... ok t/threads.t ... ok -zefram
On 2014-03-21 14:30:09, zefram@fysh.org wrote: Show quoted text
> On Perl 5.19.10:
I've bisected this between 5.19.9 and 5.19.10, identifying this commit as the cause: 7d3c8a6837b55fff0e6294ebf8c94a1601367c76 is the first bad commit commit 7d3c8a6837b55fff0e6294ebf8c94a1601367c76 Author: Steffen Mueller <smueller@cpan.org> Date: Sat Feb 22 10:08:25 2014 +0100 Optimization: Remove needless list/pushmark pairs from the OP execution This is an optimization for OP trees that involve list OPs in list context. In list context, the list OP's first child, a pushmark, will do what its name claims and push a mark to the mark stack, indicating the start of a list of parameters to another OP. Then the list's other child OPs will do their stack pushing. Finally, the list OP will be executed and do nothing but undo what the pushmark has done. This is because the main effect of the list OP only really kicks in if it's not in array context (actually, it should probably only kick in if it's in scalar context, but I don't know of any valid examples of list OPs in void contexts). This optimization is quite a measurable speed-up for array or hash slicing and some other situations. Another (contrived) example is that (1,2,(3,4)) now actually is the same, performance-wise as (1,2,3,4), albeit that's rarely relevant. The price to pay for this is a slightly convoluted (by standards other than the perl core) bit of optimization logic that has to do minor look-ahead on certain OPs in the peephole optimizer. A number of tests failed after the first attack on this problem. The failures were in two categories: a) Tests that are sensitive to details of the OP tree structure and did verbatim text comparisons of B::Concise output (ouch). These are just patched according to the new red in this commit. b) Test that validly failed because certain conditions in op.c were expecting OP_LISTs where there are now OP_NULLs (with op_targ=OP_LIST). For these, the respective conditions in op.c were adjusted. The change includes modifying B::Deparse to handle the new OP tree structure in the face of nulled OP_LISTs.
There's an identical ticket against the perl5 core for this issue at https://rt.perl.org/Ticket/Display.html?id=121342&results=bddbbc3ac2e9e758e8c7b8ff712a4dfd
This looks easy to fix. The test (l->op_type == OP_LIST) can just be changed to (l->op_type == OP_LIST || (l->op_type == OP_NULL && l->op_targ == OP_LIST)) Fix coming up.