python-greenlet / greenlet

Lightweight in-process concurrent programming
Other
1.63k stars 247 forks source link

Python 3.12: Crashes on CPython debug build when tracing #368

Open jamadden opened 1 year ago

jamadden commented 1 year ago

There's apparently some additional state we need to be saving and restoring.

Output from the test that crashes:

test_trace_events_multiple_greenlets_switching (greenlet.tests.test_tracing.TestPythonTracing.test_trace_events_multiple_greenlets_switching) ... 
Assertion failed: (code->_co_instrumentation_version == tstate->interp->monitoring_version), function call_instrumentation_vector, file instrumentation.c, line 944.
Process 92564 stopped
* thread #2, queue = 'com.apple.main-thread', stop reason = hit program assert
    frame #4: 0x0000000100cb3ae4 Python`call_instrumentation_vector.cold.13 at instrumentation.c:944:5 [opt]
   941      assert(!_PyErr_Occurred(tstate));
   942      assert(args[0] == NULL);
   943      PyCodeObject *code = frame->f_code;
-> 944      assert(code->_co_instrumentation_version == tstate->interp->monitoring_version); // assert 25 == 26
   945      assert(is_version_up_to_date(code, tstate->interp));
   946      assert(instrumentation_cross_checks(tstate->interp, code));
   947      assert(args[1] == NULL);
Target 0: (Python) stopped.
(lldb) bt
* thread #2, queue = 'com.apple.main-thread', stop reason = hit program assert
    frame #0: 0x000000018ef0c764 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x000000018ef43c28 libsystem_pthread.dylib`pthread_kill + 288
    frame #2: 0x000000018ee51ae8 libsystem_c.dylib`abort + 180
    frame #3: 0x000000018ee50e44 libsystem_c.dylib`__assert_rtn + 272
  * frame #4: 0x0000000100cb3ae4 Python`call_instrumentation_vector.cold.13 at instrumentation.c:944:5 [opt]
    frame #5: 0x0000000100b9c384 Python`call_instrumentation_vector(tstate=0x0000000100fbd780, event=15, frame=<unavailable>, instr=<unavailable>, nargs=4, args=0x000000016fdf92e0) at instrumentation.c:944:5 [opt]
    frame #6: 0x0000000100b9c438 Python`_Py_call_instrumentation_2args(tstate=<unavailable>, event=<unavailable>, frame=<unavailable>, instr=<unavailable>, arg0=<unavailable>, arg1=<unavailable>) at instrumentation.c:1022:12 [opt]
    frame #7: 0x0000000100b524bc Python`_PyEval_EvalFrameDefault(tstate=<unavailable>, frame=0x00000001031d0020, throwflag=0) at bytecodes.c:2670:31 [opt]
    frame #8: 0x0000000100b41fcc Python`_PyEval_Vector [inlined] _PyEval_EvalFrame(tstate=0x0000000100fbd780, frame=<unavailable>, throwflag=0) at pycore_ceval.h:88:16 [opt]
    frame #9: 0x0000000100b41fa4 Python`_PyEval_Vector(tstate=0x0000000100fbd780, func=0x000000010318a510, locals=0x0000000000000000, args=0x0000000100f5fdf8, argcount=0, kwnames=0x0000000000000000) at ceval.c:1675:12 [opt]
    frame #10: 0x0000000100a3d680 Python`_PyFunction_Vectorcall(func=<unavailable>, stack=<unavailable>, nargsf=0, kwnames=<unavailable>) at call.c:0:45 [opt]
    frame #11: 0x0000000100a3d32c Python`_PyVectorcall_Call(tstate=<unavailable>, func=(Python`_PyFunction_Vectorcall at call.c:410), callable=0x000000010318a510, tuple=0x0000000100f5fde0, kwargs=<unavailable>) at call.c:271:16 [opt]
    frame #12: 0x0000000100a3d458 Python`_PyObject_Call(tstate=0x0000000100fbd780, callable=0x000000010318a510, args=0x0000000100f5fde0, kwargs=0x0000000000000000) at call.c:354:16 [opt]
    frame #13: 0x0000000100a3d560 Python`PyObject_Call(callable=<unavailable>, args=<unavailable>, kwargs=<unavailable>) at call.c:379:12 [opt]
    frame #14: 0x000000010160e8a4 _greenlet.cpython-312d-darwin.so`greenlet::UserGreenlet::inner_bootstrap(this=0x000000010318f5a0, origin_greenlet=0x000000016fdf9970, _run=0x000000016fdf98c0)>&, greenlet::refs::OwnedReference<_object, &greenlet::refs::NoOpChecker(void*)>&) at greenlet.cpp:1325:45
mgorny commented 6 months ago

I'm sorry but what are the chances for this being fixed? I'd like to know whether we should wait more or look into removing greenlet from Gentoo.