Skip Menu |
Report information
Id: 122695
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: qj1020 [at] yahoo.com
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: 5.22.0



Subject: a perl interpreter bug on line number in error message
From: Jin Qian <qj1020 [...] yahoo.com>
Date: Wed, 3 Sep 2014 09:16:43 -0700
To: "perlbug [...] perl.org" <perlbug [...] perl.org>
Download (untitled) / with headers
text/plain 152b
Dear perl maintainer,

perlbug couldn't send the email on its own, so I am sending it from email account.  See the attached file for detail.

Thanks
Jin
Download rOzQQCmv0H
application/octet-stream 4.2k

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 442b
On Wed Sep 03 09:20:01 2014, qj1020@yahoo.com wrote: Show quoted text
> Dear perl maintainer, > > perlbug couldn't send the email on its own, so I am sending it from > email account. See the attached file for detail. > > Thanks > Jin
Confirmed (darwin, 5.21.3): this code: sub dummy { if ($a>3) { $a ++; } else {printf(1/0); } return 1; } dummy(); identifies the culprit as line 2, not line 5.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 630b
On Wed Sep 03 13:20:25 2014, ether wrote: Show quoted text
> On Wed Sep 03 09:20:01 2014, qj1020@yahoo.com wrote:
> > Dear perl maintainer, > > > > perlbug couldn't send the email on its own, so I am sending it from > > email account. See the attached file for detail. > > > > Thanks > > Jin
> > > Confirmed (darwin, 5.21.3): this code: > > sub dummy { > if ($a>3) { > $a ++; > } > else {printf(1/0); } > return 1; > } > dummy(); > > identifies the culprit as line 2, not line 5.
5.8.8 is fine. 5.8.9 is not. That should make bisecting pretty quick.... -- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 841b
On Wed Sep 03 17:47:32 2014, sprout wrote: Show quoted text
> On Wed Sep 03 13:20:25 2014, ether wrote:
> > On Wed Sep 03 09:20:01 2014, qj1020@yahoo.com wrote:
> > > Dear perl maintainer, > > > > > > perlbug couldn't send the email on its own, so I am sending it from > > > email account. See the attached file for detail. > > > > > > Thanks > > > Jin
> > > > > > Confirmed (darwin, 5.21.3): this code: > > > > sub dummy { > > if ($a>3) { > > $a ++; > > } > > else {printf(1/0); } > > return 1; > > } > > dummy(); > > > > identifies the culprit as line 2, not line 5.
> > 5.8.8 is fine. 5.8.9 is not. That should make bisecting pretty quick.... >
Er, never mind that. perl 5.8.8 dies at compile time. If you change it to ‘die’, then it shows line 2, too. -- Father Chrysostomos
CC: perl5-porters [...] perl.org
Subject: Re: [perl #122695] a perl interpreter bug on line number in error message
From: Paul Johnson <paul [...] pjcj.net>
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>
Date: Thu, 4 Sep 2014 10:02:04 +0100
Download (untitled) / with headers
text/plain 1.3k
On Wed, Sep 03, 2014 at 05:50:30PM -0700, Father Chrysostomos via RT wrote: Show quoted text
> On Wed Sep 03 17:47:32 2014, sprout wrote:
> > On Wed Sep 03 13:20:25 2014, ether wrote:
> > > On Wed Sep 03 09:20:01 2014, qj1020@yahoo.com wrote:
> > > > Dear perl maintainer, > > > > > > > > perlbug couldn't send the email on its own, so I am sending it from > > > > email account. See the attached file for detail. > > > > > > > > Thanks > > > > Jin
> > > > > > > > > Confirmed (darwin, 5.21.3): this code: > > > > > > sub dummy { > > > if ($a>3) { > > > $a ++; > > > } > > > else {printf(1/0); } > > > return 1; > > > } > > > dummy(); > > > > > > identifies the culprit as line 2, not line 5.
> > > > 5.8.8 is fine. 5.8.9 is not. That should make bisecting pretty quick.... > >
> > Er, never mind that. perl 5.8.8 dies at compile time. If you change it to ‘die’, then it shows line 2, too.
This is a longstanding bug/deficiency caused by having the closest COP being the if statement on line 2. Father C, you noted in the roadmap thread that fixing this (and incorrect line numbers in general) would increase memory usage (because of the need to store file/line information in more places). I think it's a price that I would be willing to pay, but it sounds like others disagree. Is that still the case? -- Paul Johnson - paul@pjcj.net http://www.pjcj.net
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 625b
On Thu Sep 04 02:02:55 2014, paul@pjcj.net wrote: Show quoted text
> Father C, you noted in the roadmap thread that fixing this (and > incorrect line numbers in general) would increase memory usage > (because > of the need to store file/line information in more places). I think > it's a price that I would be willing to pay, but it sounds like others > disagree. Is that still the case?
Speaking only for myself: I have never been bothered much by these minor inaccuracies in matching errors to line numbers. So I wouldn't want a significant increase in Perl's memory usage if that's the price we'd have to pay for such inaccuracies.
CC: Father Chrysostomos via RT <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: [perl #122695] a perl interpreter bug on line number in error message
From: demerphq <demerphq [...] gmail.com>
Date: Thu, 4 Sep 2014 13:09:16 +0200
To: Paul Johnson <paul [...] pjcj.net>
Download (untitled) / with headers
text/plain 1.5k
On 4 September 2014 11:02, Paul Johnson <paul@pjcj.net> wrote:
Show quoted text
On Wed, Sep 03, 2014 at 05:50:30PM -0700, Father Chrysostomos via RT wrote:
> On Wed Sep 03 17:47:32 2014, sprout wrote:
> > On Wed Sep 03 13:20:25 2014, ether wrote:
> > > On Wed Sep 03 09:20:01 2014, qj1020@yahoo.com wrote:
> > > > Dear perl maintainer,
> > > >
> > > > perlbug couldn't send the email on its own, so I am sending it from
> > > > email account.  See the attached file for detail.
> > > >
> > > > Thanks
> > > > Jin
> > >
> > >
> > > Confirmed (darwin, 5.21.3): this code:
> > >
> > >     sub dummy   {
> > >         if ($a>3) {
> > >             $a ++;
> > >         }
> > >         else {printf(1/0); }
> > >         return 1;
> > >     }
> > >     dummy();
> > >
> > > identifies the culprit as line 2, not line 5.
> >
> > 5.8.8 is fine.  5.8.9 is not.  That should make bisecting pretty quick....
> >
>
> Er, never mind that.  perl 5.8.8 dies at compile time.  If you change it to ‘die’, then it shows line 2, too.

This is a longstanding bug/deficiency caused by having the closest COP
being the if statement on line 2.

Father C, you noted in the roadmap thread that fixing this (and
incorrect line numbers in general) would increase memory usage (because
of the need to store file/line information in more places).  I think
it's a price that I would be willing to pay, but it sounds like others
disagree.  Is that still the case?

It would be cool if we could choose at startup with an option.

Yves 

--
perl -Mre=debug -e "/just|another|perl|hacker/"
To: demerphq <demerphq [...] gmail.com>
CC: Paul Johnson <paul [...] pjcj.net>, Father Chrysostomos via RT <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
Date: Thu, 4 Sep 2014 13:28:17 +0200
From: Rafael Garcia-Suarez <rgs [...] consttype.org>
Subject: Re: [perl #122695] a perl interpreter bug on line number in error message
Download (untitled) / with headers
text/plain 1.7k
On 4 September 2014 13:09, demerphq <demerphq@gmail.com> wrote: Show quoted text
> On 4 September 2014 11:02, Paul Johnson <paul@pjcj.net> wrote:
>> >> On Wed, Sep 03, 2014 at 05:50:30PM -0700, Father Chrysostomos via RT >> wrote:
>> > On Wed Sep 03 17:47:32 2014, sprout wrote:
>> > > On Wed Sep 03 13:20:25 2014, ether wrote:
>> > > > On Wed Sep 03 09:20:01 2014, qj1020@yahoo.com wrote:
>> > > > > Dear perl maintainer, >> > > > > >> > > > > perlbug couldn't send the email on its own, so I am sending it >> > > > > from >> > > > > email account. See the attached file for detail. >> > > > > >> > > > > Thanks >> > > > > Jin
>> > > > >> > > > >> > > > Confirmed (darwin, 5.21.3): this code: >> > > > >> > > > sub dummy { >> > > > if ($a>3) { >> > > > $a ++; >> > > > } >> > > > else {printf(1/0); } >> > > > return 1; >> > > > } >> > > > dummy(); >> > > > >> > > > identifies the culprit as line 2, not line 5.
>> > > >> > > 5.8.8 is fine. 5.8.9 is not. That should make bisecting pretty >> > > quick.... >> > >
>> > >> > Er, never mind that. perl 5.8.8 dies at compile time. If you change it >> > to ‘die’, then it shows line 2, too.
>> >> This is a longstanding bug/deficiency caused by having the closest COP >> being the if statement on line 2. >> >> Father C, you noted in the roadmap thread that fixing this (and >> incorrect line numbers in general) would increase memory usage (because >> of the need to store file/line information in more places). I think >> it's a price that I would be willing to pay, but it sounds like others >> disagree. Is that still the case?
> > > It would be cool if we could choose at startup with an option.
I think the memory usage would increase due to the OP structure being made larger -- so that would be a compile-time option.
CC: demerphq <demerphq [...] gmail.com>, Father Chrysostomos via RT <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: [perl #122695] a perl interpreter bug on line number in error message
From: Paul Johnson <paul [...] pjcj.net>
To: Rafael Garcia-Suarez <rgs [...] consttype.org>
Date: Thu, 4 Sep 2014 13:01:46 +0100
Download (untitled) / with headers
text/plain 1.2k
On Thu, Sep 04, 2014 at 01:28:17PM +0200, Rafael Garcia-Suarez wrote: Show quoted text
> On 4 September 2014 13:09, demerphq <demerphq@gmail.com> wrote:
> > On 4 September 2014 11:02, Paul Johnson <paul@pjcj.net> wrote:
> >> Father C, you noted in the roadmap thread that fixing this (and > >> incorrect line numbers in general) would increase memory usage (because > >> of the need to store file/line information in more places). I think > >> it's a price that I would be willing to pay, but it sounds like others > >> disagree. Is that still the case?
> > > > It would be cool if we could choose at startup with an option.
> > I think the memory usage would increase due to the OP structure being > made larger -- so that would be a compile-time option.
And now it's starting to sound like MAD's little cousin. I suspect it's not worth making it optional unless it can be made a runtime option. I wonder, though, whether it might be possible to make a special OP with line information, that is only used where it is necessary. That is, where the COP information which would otherwise be used is incorrect. Such a scheme, if feasible, should have a relatively low overhead, I imagine. -- Paul Johnson - paul@pjcj.net http://www.pjcj.net
Date: Thu, 4 Sep 2014 14:38:33 +0200
To: Paul Johnson <paul [...] pjcj.net>
From: Rafael Garcia-Suarez <rgs [...] consttype.org>
Subject: Re: [perl #122695] a perl interpreter bug on line number in error message
CC: demerphq <demerphq [...] gmail.com>, Father Chrysostomos via RT <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 490b
On 4 September 2014 14:01, Paul Johnson <paul@pjcj.net> wrote: Show quoted text
> I wonder, though, whether it might be possible to make a special OP with > line information, that is only used where it is necessary. That is, > where the COP information which would otherwise be used is incorrect. > Such a scheme, if feasible, should have a relatively low overhead, I > imagine.
Low memory overhead, yes, but what about the run-time overhead? Could we skip executing this op at all (like nullified ops)?
CC: perl5-porters [...] perl.org
To: James E Keenan via RT <perlbug-followup [...] perl.org>
Subject: Re: [perl #122695] a perl interpreter bug on line number in error message
From: Tim Bunce <Tim.Bunce [...] pobox.com>
Date: Thu, 4 Sep 2014 14:43:25 +0100
Download (untitled) / with headers
text/plain 528b
On Thu, Sep 04, 2014 at 03:53:42AM -0700, James E Keenan via RT wrote: Show quoted text
> > Speaking only for myself: I have never been bothered much by these minor inaccuracies in matching errors to line numbers. So I wouldn't want a significant increase in Perl's memory usage if that's the price we'd have to pay for such inaccuracies.
Just a reminder that the Devel::NYTProf statement profiler uses the line numbers to allocate timings for statements. So optionally increasing the accuracy (perhaps via a $^P bit) would be nice. Tim.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Thu Sep 04 05:02:17 2014, paul@pjcj.net wrote: Show quoted text
> On Thu, Sep 04, 2014 at 01:28:17PM +0200, Rafael Garcia-Suarez wrote:
> > On 4 September 2014 13:09, demerphq <demerphq@gmail.com> wrote:
> > > On 4 September 2014 11:02, Paul Johnson <paul@pjcj.net> wrote:
> > >> Father C, you noted in the roadmap thread that fixing this (and > > >> incorrect line numbers in general) would increase memory usage (because > > >> of the need to store file/line information in more places). I think > > >> it's a price that I would be willing to pay, but it sounds like others > > >> disagree. Is that still the case?
It was Zefram who raised the objection last time. I don’t think the memory increase would be too significant, but it’s subjective. Show quoted text
> > > It would be cool if we could choose at startup with an option.
> > > > I think the memory usage would increase due to the OP structure being > > made larger -- so that would be a compile-time option.
> > And now it's starting to sound like MAD's little cousin. I suspect it's > not worth making it optional unless it can be made a runtime option. > > I wonder, though, whether it might be possible to make a special OP with > line information, that is only used where it is necessary. That is, > where the COP information which would otherwise be used is incorrect. > Such a scheme, if feasible, should have a relatively low overhead, I > imagine.
Doesn’t sound too bad. I once wondered whether just extending entersub ops to store a line number would fix most cases (i.e., caller giving the wrong line), but that would not fix this bug. -- Father Chrysostomos
Subject: Re: [perl #122695] a perl interpreter bug on line number in error message
To: perl5-porters [...] perl.org
Date: Sun, 07 Sep 2014 16:32:33 -0500
From: Reini Urban <rurban [...] x-ray.at>
Download (untitled) / with headers
text/plain 2.3k
On 09/04/2014 10:24 AM, Father Chrysostomos via RT wrote: Show quoted text
> On Thu Sep 04 05:02:17 2014, paul@pjcj.net wrote:
>> On Thu, Sep 04, 2014 at 01:28:17PM +0200, Rafael Garcia-Suarez wrote:
>>> On 4 September 2014 13:09, demerphq <demerphq@gmail.com> wrote:
>>>> On 4 September 2014 11:02, Paul Johnson <paul@pjcj.net> wrote:
>>>>> Father C, you noted in the roadmap thread that fixing this (and >>>>> incorrect line numbers in general) would increase memory usage (because >>>>> of the need to store file/line information in more places). I think >>>>> it's a price that I would be willing to pay, but it sounds like others >>>>> disagree. Is that still the case?
> > It was Zefram who raised the objection last time. I don’t think the memory increase would be too significant, but it’s subjective. >
>>>> It would be cool if we could choose at startup with an option.
>>> >>> I think the memory usage would increase due to the OP structure being >>> made larger -- so that would be a compile-time option.
>> >> And now it's starting to sound like MAD's little cousin. I suspect it's >> not worth making it optional unless it can be made a runtime option. >> >> I wonder, though, whether it might be possible to make a special OP with >> line information, that is only used where it is necessary. That is, >> where the COP information which would otherwise be used is incorrect. >> Such a scheme, if feasible, should have a relatively low overhead, I >> imagine.
> > Doesn’t sound too bad. I once wondered whether just extending entersub ops to store a line number would fix most cases (i.e., caller giving the wrong line), but that would not fix this bug.
Looks like you cannot remember my old oplines patch from 2008, which showed that moving the line from the COP to every OP will save ~8% memory and a small amount (2-5%) of runtime. smaller and faster, not bigger. There is still work to be done, which I didn't want to do alone then, but the general idea proves the opposite to what you are talking about here. TODO: 1. debugging needs to add state ops, instead of just switching from nextstate; 2. errors and warnings need to walk more back, instead of just to the prev. line to the prev. block. as small side-effect this little artefact would also have been fixed, but the general improvements are much bigger than just reporting the right line number.
Download oplines1.patch
text/plain 63k

Message body is not shown because sender requested not to inline it.

Download oplines1.pl
text/x-perl 3.8k

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 317b
On Sun Sep 07 14:33:30 2014, rurban wrote: Show quoted text
> Looks like you cannot remember my old oplines patch from 2008, which > showed that moving the line from the COP to every OP will save ~8% > memory and a small amount (2-5%) of runtime. smaller and faster, not > bigger.
Do you have a message id? -- Father Chrysostomos
Date: Mon, 8 Sep 2014 13:11:22 +0100
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #122695] a perl interpreter bug on line number in error message
To: Reini Urban <rurban [...] x-ray.at>
CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
On Sun, Sep 07, 2014 at 04:32:33PM -0500, Reini Urban wrote: Show quoted text
> Looks like you cannot remember my old oplines patch from 2008, which showed > that moving the line from the COP to every OP will save ~8% memory and a > small amount (2-5%) of runtime. smaller and faster, not bigger.
From the comments in your patch, you assume 4 ops per line. This seems somewhat low. A quick run of regen/opcode.pl (I just picked it because it happens to be something I've worked on recently) shows nextstates represent about 1 in 11 compiled ops (as shown by -Dx), and 1 in 8 op executions (as shown by -Dt). Show quoted text
> There is still work to be done, which I didn't want to do alone then, but > the general idea proves the opposite to what you are talking about here.
Its not clear to me from this diff how you intend handle the nextstate actions (e.g. resetting PL_stack_sp) in the absence of nextstate ops. You seem to be moving that into the runops loop; in that case I would expect a larger overhead for having to check for a "nextstateish" action for every op, rather than just doing the nextstate when needed. -- 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
Subject: Re: [perl #122695] a perl interpreter bug on line number in error message
CC: perl5 porters <perl5-porters [...] perl.org>
Date: Mon, 8 Sep 2014 09:58:22 -0400
To: perlbug-followup <perlbug-followup [...] perl.org>
From: Eric Brine <ikegami [...] adaelis.com>
On Thu, Sep 4, 2014 at 11:24 AM, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote:
Show quoted text
On Thu Sep 04 05:02:17 2014, paul@pjcj.net wrote:
> On Thu, Sep 04, 2014 at 01:28:17PM +0200, Rafael Garcia-Suarez wrote:
> > On 4 September 2014 13:09, demerphq <demerphq@gmail.com> wrote:
> > > On 4 September 2014 11:02, Paul Johnson <paul@pjcj.net> wrote:
> > >> Father C, you noted in the roadmap thread that fixing this (and
> > >> incorrect line numbers in general) would increase memory usage (because
> > >> of the need to store file/line information in more places).  I think
> > >> it's a price that I would be willing to pay, but it sounds like others
> > >> disagree.  Is that still the case?

It was Zefram who raised the objection last time.  I don’t think the memory increase would be too significant, but it’s subjective.

Hold on. Like the OP said, you get the right line number if you add a space in front of the printf. Why would the fix require more memory that if the user had inserted a space?

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 810b
On Mon Sep 08 06:58:48 2014, ikegami@adaelis.com wrote: Show quoted text
> On Thu, Sep 4, 2014 at 11:24 AM, Father Chrysostomos via RT < > perlbug-followup@perl.org> wrote:
> > It was Zefram who raised the objection last time. I don’t think the > > memory increase would be too significant, but it’s subjective. > >
> > Hold on. Like the OP said, you get the right line number if you add a > space > in front of the printf. Why would the fix require more memory that if > the > user had inserted a space?
Whitespace differences can change which line number is stored for a multi-line statement, but ultimately the underlying problem still exists: only one line number per statement. So if you have die() twice in the same statement, on different lines, one of them will give the wrong number. -- Father Chrysostomos
From: Eric Brine <ikegami [...] adaelis.com>
Date: Mon, 8 Sep 2014 13:02:13 -0400
To: perlbug-followup <perlbug-followup [...] perl.org>
CC: perl5 porters <perl5-porters [...] perl.org>
Subject: Re: [perl #122695] a perl interpreter bug on line number in error message
Download (untitled) / with headers
text/plain 474b
On Mon, Sep 8, 2014 at 11:33 AM, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote:
Show quoted text
but ultimately the underlying problem still exists: only one line number per statement.  So if you have die() twice in the same statement, on different lines, one of them will give the wrong number.

I'm quite aware of that, but that's a different problem (and one I can live with).

In this case, it's the opposite problem. We have two statements and one line number.

Date: Mon, 8 Sep 2014 13:49:07 -0500
To: Dave Mitchell <davem [...] iabyn.com>, pp <perl5-porters [...] perl.org>
From: Reini Urban <rurban [...] x-ray.at>
Subject: Re: [perl #122695] a perl interpreter bug on line number in error message
Download (untitled) / with headers
text/plain 1.8k
On Mon, Sep 8, 2014 at 7:11 AM, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Sun, Sep 07, 2014 at 04:32:33PM -0500, Reini Urban wrote:
>> Looks like you cannot remember my old oplines patch from 2008, which showed >> that moving the line from the COP to every OP will save ~8% memory and a >> small amount (2-5%) of runtime. smaller and faster, not bigger.
> > From the comments in your patch, you assume 4 ops per line. This seems > somewhat low. A quick run of regen/opcode.pl (I just picked it because > it happens to be something I've worked on recently) shows nextstates > represent about 1 in 11 compiled ops (as shown by -Dx), and 1 in 8 op > executions (as shown by -Dt).
See the 2nd attached file oplines1.pl which creates a simple test module to calculate the respective changes. It's measured, not assumed. Show quoted text
>> There is still work to be done, which I didn't want to do alone then, but >> the general idea proves the opposite to what you are talking about here.
> > Its not clear to me from this diff how you intend handle the nextstate > actions (e.g. resetting PL_stack_sp) in the absence of nextstate ops. You > seem to be moving that into the runops loop; in that case I would expect a > larger overhead for having to check for a "nextstateish" action for every > op, rather than just doing the nextstate when needed.
Yes. cops for stack resets and more are preserved in perly.y and op.c. I haven't checked it exactly yet, but I was assuming only scope enter, exits and entersub need the nextstate actions (stack reset, TAINT_NOT, FREETMPS). I played with it in B::CC some years ago. See http://blogs.perl.org/users/rurban/2012/10/optimizing-compiler-benchmarks-part-4.html I updated my oplines patch to blead at my github, in case anyone wants to continue. https://github.com/rurban/perl/tree/oplines Make test passes. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 323b
On Mon Sep 08 11:49:30 2014, rurban wrote: Show quoted text
> I haven't checked it exactly yet, but I was assuming only scope enter, > exits > and entersub need the nextstate actions (stack reset, TAINT_NOT, > FREETMPS).
Most ops still push on to the stack even in void context. Does that affect your statement? -- Father Chrysostomos
To: Reini Urban <rurban [...] x-ray.at>
CC: pp <perl5-porters [...] perl.org>
From: Dave Mitchell <davem [...] iabyn.com>
Date: Tue, 9 Sep 2014 12:00:58 +0100
Subject: Re: [perl #122695] a perl interpreter bug on line number in error message
Download (untitled) / with headers
text/plain 1.9k
On Mon, Sep 08, 2014 at 01:49:07PM -0500, Reini Urban wrote: Show quoted text
> > From the comments in your patch, you assume 4 ops per line. This seems > > somewhat low. A quick run of regen/opcode.pl (I just picked it because > > it happens to be something I've worked on recently) shows nextstates > > represent about 1 in 11 compiled ops (as shown by -Dx), and 1 in 8 op > > executions (as shown by -Dt).
> > See the 2nd attached file oplines1.pl which creates a simple test > module to calculate > the respective changes. > It's measured, not assumed.
So you have a test file which measures at 4 ops/line, while I have a perl file that measures at 8-11 ops/line. Both are of course correct. But its not clear which one of the two is more typical. So you can't conclude from that data that 4 is typical. Show quoted text
> > Its not clear to me from this diff how you intend handle the nextstate > > actions (e.g. resetting PL_stack_sp) in the absence of nextstate ops. You > > seem to be moving that into the runops loop; in that case I would expect a > > larger overhead for having to check for a "nextstateish" action for every > > op, rather than just doing the nextstate when needed.
> > Yes. cops for stack resets and more are preserved in perly.y and op.c. > I haven't checked it exactly yet, but I was assuming only scope enter, exits > and entersub need the nextstate actions (stack reset, TAINT_NOT, > FREETMPS).
That's very wrong. In the following examples, removing the nextstate marked by <;> will give: #!perl -T $x = $^X <;> $y = $z+1; # $y now tainted sub DESTROY { print "DESTROY\n" } $r = bless [ 1,2,3 ]; $r = $r->[0] <;> print "ok\n"; # "DESTROY" now printed *after* "ok" I can't immediately think of any behavioural changes from not resetting the stack, but it *will* cause the stack to be unnecessarily extended, as it accumulates any detritus from *every* statement in the block. -- Monto Blanco... scorchio!
From: bulk88 <bulk88 [...] hotmail.com>
Date: Tue, 9 Sep 2014 07:47:02 -0400
Subject: Re: [perl #122695] a perl interpreter bug on line number in errormessage
To: Dave Mitchell <davem [...] iabyn.com>
CC: Reini Urban <rurban [...] x-ray.at>, pp <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 763b
Dave Mitchell wrote: Show quoted text
> That's very wrong. In the following examples, removing the nextstate > marked by <;> will give: > > #!perl -T > $x = $^X <;> > $y = $z+1; # $y now tainted > > > sub DESTROY { print "DESTROY\n" } > $r = bless [ 1,2,3 ]; > $r = $r->[0] <;> > print "ok\n"; # "DESTROY" now printed *after* "ok" > > I can't immediately think of any behavioural changes from not resetting the > stack, but it *will* cause the stack to be unnecessarily extended, as it > accumulates any detritus from *every* statement in the block. >
IIRC the stack is extended by a couple hundreds of ptrs by the time run phase is reached. Therefore there is plenty of space to collect a couple non list context statements onto it.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 721b
On Mon Sep 08 10:02:50 2014, ikegami@adaelis.com wrote: Show quoted text
> On Mon, Sep 8, 2014 at 11:33 AM, Father Chrysostomos via RT < > perlbug-followup@perl.org> wrote: >
> > but ultimately the underlying problem still exists: only one line number > > per statement. So if you have die() twice in the same statement, on > > different lines, one of them will give the wrong number. > >
> > I'm quite aware of that, but that's a different problem (and one I can live > with). > > In this case, it's the opposite problem. We have two statements and one > line number.
Sorry. I was so stuck on the harder problem, I didn’t see the obvious. Something is probably up with copline. I’ll look into this. -- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
Fixed in 51a82aa9fb2. -- Father Chrysostomos
Subject: Your ticket against Perl 5 has been resolved
Download (untitled) / with headers
text/plain 222b
Thanks for submitting this ticket The issue should be resolved with the release today of Perl v5.22. If you find that the problem persists, feel free to reopen this ticket -- Karl Williamson for the Perl 5 porters team


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