closes bpo-34588: Fix an off-by-one error in traceback formatting. by benjaminp · Pull Request #9077 · python/cpython (original) (raw)
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation4 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
The recursive frame pruning code always undercounted the number of elided frames
by one. That is, in the "[Previous line repeated N more times]" message, N would
always be one too few. Near the recursive pruning cutoff, one frame could be
silently dropped. That situation is demonstrated in the OP of the bug report.
The fix is to start the identical frame counter at 1.
https://bugs.python.org/issue34588
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some new lines are longer than 79 characters. Besides this LGTM.
The recursive frame pruning code always undercounted the number of elided frames by one. That is, in the "[Previous line repeated N more times]" message, N would always be one too few. Near the recursive pruning cutoff, one frame could be silently dropped. That situation is demonstrated in the OP of the bug report.
The fix is to start the identical frame counter at 1.
Thanks @benjaminp for the PR 🌮🎉.. I'm working now to backport this PR to: 3.6, 3.7.
🐍🍒⛏🤖
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request
The recursive frame pruning code always undercounted the number of elided frames by one. That is, in the "[Previous line repeated N more times]" message, N would always be one too few. Near the recursive pruning cutoff, one frame could be silently dropped. That situation is demonstrated in the OP of the bug report.
The fix is to start the identical frame counter at 1. (cherry picked from commit d545869)
Co-authored-by: Benjamin Peterson benjamin@python.org
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request
The recursive frame pruning code always undercounted the number of elided frames by one. That is, in the "[Previous line repeated N more times]" message, N would always be one too few. Near the recursive pruning cutoff, one frame could be silently dropped. That situation is demonstrated in the OP of the bug report.
The fix is to start the identical frame counter at 1. (cherry picked from commit d545869)
Co-authored-by: Benjamin Peterson benjamin@python.org
miss-islington added a commit that referenced this pull request
The recursive frame pruning code always undercounted the number of elided frames by one. That is, in the "[Previous line repeated N more times]" message, N would always be one too few. Near the recursive pruning cutoff, one frame could be silently dropped. That situation is demonstrated in the OP of the bug report.
The fix is to start the identical frame counter at 1. (cherry picked from commit d545869)
Co-authored-by: Benjamin Peterson benjamin@python.org
miss-islington added a commit that referenced this pull request
The recursive frame pruning code always undercounted the number of elided frames by one. That is, in the "[Previous line repeated N more times]" message, N would always be one too few. Near the recursive pruning cutoff, one frame could be silently dropped. That situation is demonstrated in the OP of the bug report.
The fix is to start the identical frame counter at 1. (cherry picked from commit d545869)
Co-authored-by: Benjamin Peterson benjamin@python.org