Coverage.py bug reports nedbat/coveragepy#1022 and nedbat/coveragepy#959 demonstrate the same Python code, with the same disassembly, executing differently.

In https://discuss.python.org/t/same-python-version-different-optimizations-on-different-os/5098, Ammar Askar said:

For any core developer who wants to look into this, based on my preliminary research this seems to be related to opcode prediction and computed GOTOS.

If you put #define USE_COMPUTED_GOTOS 0 above https://github.com/python/cpython/blob/master/Python/ceval.c#L1033 then this issue is re-creatable on Linux/Mac.

It seems to be an issue relating to how f_lasti is updated.

minimal reproducer without coverage:

import sys

def f():
    try:
        for i in []: pass
        return 1
    except:
        return 2

def tracer(frame, event, _):
    if event == 'line':
        print("executing line {}".format(frame.f_lineno))
    return tracer

sys.settrace(tracer)
f()

With computed gotos this results in:

executing line 4
executing line 5
executing line 6

but without:

executing line 4
executing line 5

So I think this is a weird edge case with a set of opcode predictions (GET_ITER -> FOR_ITER -> POP_BLOCK) going outside of a line boundary.

The disassembly of the reproducer above is:

4 0 SETUP_FINALLY 16 (to 18)

5 2 LOAD_CONST 1 (())
4 GET_ITER
>> 6 FOR_ITER 4 (to 12)
8 STORE_FAST 0 (i)
10 JUMP_ABSOLUTE 6

6 >> 12 POP_BLOCK
14 LOAD_CONST 2 (1)
16 RETURN_VALUE

When computed gotos are disabled and there is a tracing function, instructions 0, 2, 4, 14 and 16 hit the fast_next_opcode label and have a chance to be traced as line hits. Note that maybe_call_line_trace will only cause a line hit if the instruction that starts a line (POP_BLOCK in this case) is being executed.

When computed gotos are enabled, DISPATCH is a no-op and there is a special case for when tracing is enabled that causes every opcode to go through fast_next_opcode:

When computed gotos are not enabled, there is no similar check for PREDICT (and might be too costly to add) causing this issue:

A couple of things to fix here.

Firstly, the PREDICTion of POP_BLOCK in FOR_ITER shouldn't be there. POP_BLOCK doesn't normally occur after a loop and hasn't since we removed "pseudo exceptions" from the interpreter a couple of years ago.

Secondly, there is the issue of PREDICTs skipping tracing.
Either we can make sure that no PREDICTs cross a line boundary, which seems error prone, or we add the check for tracing into the PREDICT macro, which seems more robust.

New changeset 17b5be0 by Mark Shannon in branch 'master':
bpo-41670: Remove outdated predict macro invocation. (GH-22026)
17b5be0