Description

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'

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

1. 15r10nk commented on Apr 5, 2022

   

   15r10nkmannequin

   on Apr 5, 2022

   MannequinAuthor

   More actions

   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.
2. 15r10nk

   added

   3.11only security fixesonly security fixes

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Apr 5, 2022
3. brandtbucher commented on Apr 5, 2022

   

   brandtbucher

   on Apr 5, 2022

   Member

   More actions

   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?
4. 15r10nk commented on Apr 7, 2022

   

   15r10nkmannequin

   on Apr 7, 2022

   MannequinAuthor

   More actions

   I moved the line.
   Is there anything else required? unittests?
5. ezio-melotti

   transferred this issue fromon Apr 10, 2022
6. 15r10nk commented on Apr 20, 2022

   

   15r10nk

   on Apr 20, 2022

   ContributorAuthor

   More actions

   The problem was fixed with e590379.
7. brandtbucher commented on Apr 20, 2022

   

   brandtbucher

   on Apr 20, 2022

   Member

   More actions

   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).
8. 15r10nk commented on Apr 20, 2022

   

   15r10nk

   on Apr 20, 2022

   ContributorAuthor

   More actions

   yes, I bisected it down to this commit.
9. 15r10nk commented on Apr 20, 2022

   

   15r10nk

   on Apr 20, 2022

   ContributorAuthor

   More actions

   wait, maybe cache_counter gets never >0 in my tests ... the bug might be still there.
10. 15r10nk commented on Apr 20, 2022

    

    15r10nk

    on Apr 20, 2022

    ContributorAuthor

    More actions

    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.
11. brandtbucher

    added 3 commits that reference this issue on Jun 16, 2022

    GH-91389: Fix dis position information for CACHEs (GH-93663)

    f8e576b

    pythonGH-91389: Fix dis position information for CACHEs (pythonGH-93663)

    558f31f

    GH-91389: Fix dis position information for CACHEs (GH-93663) (GH-93921)

    05d83a7
12. brandtbucher

    closed this as completedon Jun 17, 2022
13. serhiy-storchaka

    added a commit that references this issue on Jun 26, 2022

    Revert 30935 defer bpo45162 to 312 (#94285)

    1ffde3e

Issue actions