Skip to content

closes bpo-34588: Fix an off-by-one error in traceback formatting. #9077

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 and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 10, 2018

Conversation

benjaminp
Copy link
Contributor

@benjaminp benjaminp commented Sep 6, 2018

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

Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

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.
@benjaminp benjaminp force-pushed the benjamin-traceback-obo branch from 02bf184 to 59936ae Compare September 10, 2018 05:27
@benjaminp benjaminp merged commit d545869 into master Sep 10, 2018
@miss-islington
Copy link
Contributor

Thanks @benjaminp for the PR 🌮🎉.. I'm working now to backport this PR to: 3.6, 3.7.
🐍🍒⛏🤖

@benjaminp benjaminp deleted the benjamin-traceback-obo branch September 10, 2018 15:43
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Sep 10, 2018
…-9077)

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>
@bedevere-bot
Copy link

GH-9134 is a backport of this pull request to the 3.7 branch.

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Sep 10, 2018
…-9077)

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>
@bedevere-bot
Copy link

GH-9135 is a backport of this pull request to the 3.6 branch.

miss-islington added a commit that referenced this pull request Sep 10, 2018
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 Sep 10, 2018
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants