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 likeCALL withINSTRUMENTED_CALL.
2. Disable instrumentation. Note that this doesn't immediately changeINSTRUMENTED_CALL back toCALL!
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 themonitors_are_empty check above returns with instrumenting the bytecode. Missing events!

Adapted from@pablogsal's repro:

importsysimportthreadingimportdisdeflooooooser(x):print("I am a looooooser")defLOSER():looooooser(42)TRACES= []deftracing_function(frame,event,arg):function_name=frame.f_code.co_nameTRACES.append((function_name,event,arg))deffunc1():sys.setprofile(tracing_function)LOSER()sys.setprofile(None)TRACES.clear()deffunc2():defthread_body():sys.setprofile(tracing_function)LOSER()sys.setprofile(None)dis.dis(looooooser,adaptive=True)# WHENbg_thread=threading.Thread(target=thread_body)bg_thread.start()bg_thread.join()fortraceinTRACES:print(trace)assert ('looooooser','call',None)inTRACESfunc1()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
• [3.14] gh-136396: Include instrumentation when creating new copies of the bytecode (GH-136525) #136657