Bug report

Bug description:

A bunch of the instrumentation state is per-code object, such as the active montiors. The modifications also typically happen lazily when a code object is executed after instrumentation is enabled/disabled.

However, if you create a new thread, then it will be initialized without the instrumented bytecodes. Here's an example that breaks:

1. Enable instrumentation and call some function. This will replace things like CALL with INSTRUMENTED_CALL.
2. Disable instrumentation. Note that this doesn't immediately change INSTRUMENTED_CALL back to CALL!
3. Start a new thread, enable instrumentation, and call that same function - uh oh!

In (3), the new thread gets a clean copy of the bytecode without instrumentation:

However, the code object still has instrumentation enabled, so the monitors_are_empty check above returns with instrumenting the bytecode. Missing events!

Adapted from @pablogsal's repro:

import sys
import threading
import dis

def looooooser(x):
    print("I am a looooooser")

def LOSER():
    looooooser(42)

TRACES = []

def tracing_function(frame, event, arg):
    function_name = frame.f_code.co_name
    TRACES.append((function_name, event, arg))

def func1():
    sys.setprofile(tracing_function)
    LOSER()
    sys.setprofile(None)
    TRACES.clear()

def func2():
    def thread_body():
        sys.setprofile(tracing_function)
        LOSER()
        sys.setprofile(None)

    dis.dis(looooooser, adaptive=True)

    # WHEN
    bg_thread = threading.Thread(target=thread_body)
    bg_thread.start()

    bg_thread.join()

    for trace in TRACES:
        print(trace)
    assert ('looooooser', 'call', None) in TRACES

func1()
func2()

cc @mpage

CPython versions tested on:

CPython main branch, 3.14, 3.15

Operating systems tested on:

No response

Linked PRs

• gh-136396: Include instrumentation when creating new copies of the bytecode #136525