show_caches option affects code positions reported by dis.get_instructions(...)

[15r10nk]

BPO	47233
Nosy	@brandtbucher, @15r10nk
PRs	gh-91389: Fix show_caches in dis module #32406
Files	test2.py

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2022-04-05.19:47:24.937>
labels = ['type-bug', '3.11']
title = 'show_caches option affects code positions reported by dis.get_instructions(...)'
updated_at = <Date 2022-04-07.20:52:49.864>
user = 'https://github.com/15r10nk'

bugs.python.org fields:

activity = <Date 2022-04-07.20:52:49.864>
actor = '15r10nk'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2022-04-05.19:47:24.937>
creator = '15r10nk'
dependencies = []
files = ['50722']
hgrepos = []
issue_num = 47233
keywords = ['patch']
message_count = 3.0
messages = ['416810', '416828', '416944']
nosy_count = 2.0
nosy_names = ['brandtbucher', '15r10nk']
pr_nums = ['32406']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue47233'
versions = ['Python 3.11']

[15r10nk]

The Instructions reported by dis.get_instructions(...) and dis.Bytecode(...) have different positions depending on the value of their show_caches argument.

test2.py reproduces the problem.

[brandtbucher]

Nice catch. The fix should be pretty simple: just move this line...

cpython/Lib/dis.py

Line 425 in c1d93b6

positions = Positions(*next(co_positions, ()))

...up to the top of the for loop.

Are you interested in working on this?

[15r10nk]

I moved the line.
Is there anything else required? unittests?

[15r10nk]

The problem was fixed with e590379.

[brandtbucher]

Was it? I haven't run it yet, but that patch doesn't look like it fixed the issue (there's still an early continue at the top of the loop).

[15r10nk]

yes, I bisected it down to this commit.

[15r10nk]

wait, maybe cache_counter gets never >0 in my tests ... the bug might be still there.

[15r10nk]

I have verified that the cache_counter gets >0 in my tests.

I think the CACHE instructions have no corresponding positions in co_positions. It always continues the loop if the cache_conter is > 0.

I think the current implementation is has no bug.