Closed p5pRT closed 9 years ago
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
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.
The RT System itself - Status changed from 'new' to 'open'
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....
--
Father Chrysostomos
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.
--
Father Chrysostomos
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?
-- Paul Johnson - paul@pjcj.net http://www.pjcj.net
On Thu Sep 04 02:02:55 2014\, 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?
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.
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.
Yves
-- perl -Mre=debug -e "/just|another|perl|hacker/"
On 4 September 2014 13:09\, demerphq \demerphq@​gmail\.com wrote:
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.
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 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
On 4 September 2014 14:01\, Paul Johnson \paul@​pjcj\.net wrote:
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)?
On Thu\, Sep 04\, 2014 at 03:53:42AM -0700\, James E Keenan via RT wrote:
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.
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.
--
Father Chrysostomos
On 09/04/2014 10:24 AM\, Father Chrysostomos via RT wrote:
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.
On Sun Sep 07 14:33:30 2014\, rurban 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.
Do you have a message id?
--
Father Chrysostomos
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).
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
On Thu\, Sep 4\, 2014 at 11:24 AM\, Father Chrysostomos via RT \< perlbug-followup@perl.org> wrote:
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?
On Mon Sep 08 06:58:48 2014\, ikegami@adaelis.com wrote:
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
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.
On Mon\, Sep 8\, 2014 at 7:11 AM\, Dave Mitchell \davem@​iabyn\.com wrote:
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.
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/
On Mon Sep 08 11:49:30 2014\, rurban wrote:
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
On Mon\, Sep 08\, 2014 at 01:49:07PM -0500\, Reini Urban wrote:
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.
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!
Dave Mitchell wrote:
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.
On Mon Sep 08 10:02:50 2014\, ikegami@adaelis.com wrote:
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
Fixed in 51a82aa9fb2.
--
Father Chrysostomos
@cpansprout - Status changed from 'open' to 'pending release'
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
@khwilliamson - Status changed from 'pending release' to 'resolved'
Migrated from rt.perl.org#122695 (status was 'resolved')
Searchable as RT122695$