`ctypes.util._info_callback` (dl_iterate_phdr) closure causes SIGABRT in child after `os.fork()`
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 77.2k
- フォーク
- 35.9k
- PR マージ指標
- PR 指標を取得中
説明
Crash report
What happened?
ctypes.util._info_callback (dl_iterate_phdr) closure causes SIGABRT in child after os.fork()
Versions: Python 3.14.5, Linux x86_64, libffi 3.4.x (/lib64/libffi.so.8)
Hi all,
I have updated my code library from Python3.9 to 3.14. I have noticed that stopping my Python service produced core dumps. My service has a parent which forks multiple children which use scikit-learn.
I could reproduce a minimal running code with a coredump. Sorry, I am not sure, whether it is threadpoolctl or CPython issue. Thus, I opened an issue at threadpoolctl as well.
Below you will find the structured output summarized by our glorious AI overlords.
Thanks!
Problem
If ctypes.util.find_library() (or ctypes.util.dllist()) is called in a
parent process — which lazily creates and caches the module-level
ctypes.CFUNCTYPE closure ctypes.util._info_callback used by the
dl_iterate_phdr()-based lookup added in gh-119349 — and the process then
calls os.fork(), the forked child reliably SIGABRTs when it later exits
via sys.exit()/Py_Finalize():
abort
dlfree.cold (libffi.so.8)
CThunkObject_dealloc (_ctypes.cpython-314-x86_64-linux-gnu.so)
_Py_Dealloc
dict_dealloc
_Py_Dealloc
PyCData_clear (_ctypes)
PyCFuncPtr_dealloc (_ctypes)
_Py_Dealloc
insertdict.isra.0
_PyModule_ClearDict
finalize_modules
_Py_Finalize
Py_Exit
handle_system_exit
...
Py_RunMain
Py_BytesMain
The abort is inside libffi's own private closure allocator (dlfree in
libffi.so.8), not glibc's malloc (confirmed via MALLOC_CHECK_=3, which
had no effect).
Minimal repro
import os, sys, signal, time
from ctypes.util import find_library
find_library("c") # creates ctypes.util._info_callback in the parent
def child():
signal.signal(signal.SIGTERM, lambda s, f: sys.exit(0))
find_library("c")
time.sleep(30)
pid = os.fork()
if pid == 0:
child()
else:
time.sleep(3)
os.kill(pid, signal.SIGTERM)
os.waitpid(pid, 0)
python3.14 repro.py → Aborted (core dumped) in the child.
Notes:
- Calling
find_library()alone (no fork) does not crash. os.fork()alone (no priorctypes.utilactivity) does not crash.- Only the combination — closure created pre-fork, then freed at shutdown
in the child — reproduces it. - This did not occur on Python 3.9, since the
dl_iterate_phdr-based
ctypes.utilimplementation (gh-119349) did not exist there.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Output from running 'python -VV' on the command line:
No response
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、レポートで説明されている ctypes.util.find_library()、ctypes.util.dllist()、および遅延作成される _info_callback から始め、次に CPython 3.14 を使って Linux 上で最小の os.fork() 例を再現します。示されている libffi と _ctypes の解放経路を通じて、子プロセスの終了処理を追跡します。callback が fork() 前に作成された後、子プロセスが SIGABRT なしで終了すれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- backend, operating-systems
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 静か
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 38/100