[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

Change by Erlend E. Aasland : -- nosy: +erlendaasland ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

David Edelsohn added the comment: It seems that PyOS_AfterFork_Child() needs to do something like PyThreadState *tstate = PyThreadState_Get(); PyObject *wr = _PyObject_CAST(tstate->on_delete_data); PyObject *obj = PyWeakref_GET_OBJECT(wr); lockobject *lock; if (obj != Py_None) { lock =

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

David Edelsohn added the comment: How could release_sentinel() be structured to not call PyThread_release_lock()? This seems to be a situation where _PyThreadState_DeleteExcept() is deleting all thread states. thread__set_sentinel() sets release_sentinel() as its on_delete hook. The thread

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

Change by David Edelsohn : -- nosy: +David.Edelsohn ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

Michael Felt added the comment: Willing to spend more time on this - but the variable names chosen blind me - looks like a circle. And, thinking about the address in the core dump starting with 0xd (segment 13) - confuses me somewhat - as from memory - I thought the shared library

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

Michael Felt added the comment: OK. Please explain. Looking at tstate assignment In posixmodule.c:PyOSAfterFork_Child() PyStatus status; _PyRuntimeState *runtime = &_PyRuntime; ... PyThreadState *tstate = _PyThreadState_GET(); and later calls status =

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

Michael Felt added the comment: OK: further. Two options are suggested: There are different options to solve this issue: * Reset _tstate_lock before using it... not sure that it's worth it, since we are going to delete the threading.Thread object with its _tstate_lock object anymore.

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

STINNER Victor added the comment: > As this seem to be a long-standing issue is it perhaps a possibility to > change the test so that the bot can go green again? This issue is a real crash and it seems quite easy to get it. I prefer to not hide the bug in the test suite. The bug must be

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

Michael Felt added the comment: Adding 3.10. While a (sort of) duplicate I also would like to add that before revision "7cb033c423b65def1632d6c3c747111543b342a2" this was not showing up as an issue with test_importlib. my issue was with test_importlib suddenly going into error. As this

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

STINNER Victor added the comment: I marked bpo-43665 "AIX: test_importlib regression (ENV change)" as a duplicate of this issue. test_multiprocessing_pool_circular_import() of test_importlib now triggers this crash as well. -- ___ Python tracker

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

hai shi added the comment: > "since we are going to delete the threading.Thread object with its > _tstate_lock object anyway" sentence is a description of the current > _PyThreadState_DeleteExcept() implementation. Oh, got it. thanks for your explanation :) --

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

STINNER Victor added the comment: > Do we have any pep or discuss record about this plan? "since we are going to delete the threading.Thread object with its _tstate_lock object anyway" sentence is a description of the current _PyThreadState_DeleteExcept() implementation. --

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

hai shi added the comment: >since we are going to delete the threading.Thread object with its _tstate_lock >object anymore. Do we have any pep or discuss record about this plan? > * Modify release_sentinel() to not use the lock: avoid > PyThread_release_lock() call. Hm, I am not sure

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

Change by hai shi : -- nosy: +shihai1991 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

STINNER Victor added the comment: See also bpo-40089: "Add _at_fork_reinit() method to locks". -- ___ Python tracker ___ ___

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

New submission from STINNER Victor : At fork, Python calls PyOS_AfterFork_Child() in the child process which indirectly calls _PyThreadState_DeleteExcept() whichs calls release_sentinel() of the thread which releases the thread state lock (threading.Thread._tstate_lock). Problem: using a