Repository navigation
show_caches option affects code positions reported by dis.get_instructions(...) #91389
Description
| BPO | 47233 |
|---|---|
| Nosy | @brandtbucher, @15r10nk |
| PRs | |
| Files |
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']
Activity
15r10nk commented on Apr 5, 2022
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 commented on Apr 5, 2022
Nice catch. The fix should be pretty simple: just move this line...
cpython/Lib/dis.py
Line 425 in c1d93b6
...up to the top of the for loop.
Are you interested in working on this?
15r10nk commented on Apr 7, 2022
I moved the line.
Is there anything else required? unittests?
15r10nk commented on Apr 20, 2022
The problem was fixed with e590379.
brandtbucher commented on Apr 20, 2022
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 commented on Apr 20, 2022
yes, I bisected it down to this commit.
15r10nk commented on Apr 20, 2022
wait, maybe cache_counter gets never >0 in my tests ... the bug might be still there.
15r10nk commented on Apr 20, 2022
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.
GH-91389: Fix dis position information for CACHEs (GH-93663)
pythonGH-91389: Fix dis position information for CACHEs (pythonGH-93663)
GH-91389: Fix dis position information for CACHEs (GH-93663) (GH-93921)
Revert 30935 defer bpo45162 to 312 (#94285)