Repository navigation
Crash in clear_weakref() in pydantic test suite, in 3.12.0rc1 and newer #108295
Copy link
Copy link
Closed
Labels
3.12only security fixesonly security fixes3.13only security fixesonly security fixesrelease-blockertopic-typingtype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump
Description
Crash report
CPython versions tested on:
3.12, CPython main branch
Operating systems tested on:
Linux
Output from running 'python -VV' on the command line:
Python 3.12.0rc1+ (heads/3.12:149d70c254, Aug 22 2023, 16:11:47) [GCC 13.2.0]
What happened?
The pydantic test suite started causing pytest to segfault on exit recently, with Python 3.12. I've been able to bisect it to pydantic commit pydantic/pydantic@f5e3aa9 that looks relatively harmless. I've also been able to bisect CPython into commit 58f9c88:
gh-106403: Restore weakref support for TypeVar and friends (GH-106418)
I have been able to reproduce the problem with tip of main as well, though I have to note it's a bit of heisenbug. I've basically had a very lucky day today that I've managed to correctly bisect on the second attempt.
To reproduce:
git clone https://github.com/pydantic/pydantic/
cd pydantic
python -m venv .venv
. .venv/bin/activate
pip install -e . pytest dirty-equals
# may need to be repeated a few times
python -m pytest -o addopts= tests/test_generics.py --deselect tests/test_generics.py::test_partial_specification_name -s
Error messages
Backtrace
Core was generated by `python -m pytest -o addopts= tests/test_generics.py --deselect tests/test_gener'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 clear_weakref (self=self@entry=0x7f0a9a171df0) at Objects/weakrefobject.c:62
62 if (*list == self)
(gdb) bt
#0 clear_weakref (self=self@entry=0x7f0a9a171df0) at Objects/weakrefobject.c:62
#1 0x0000557c3663d843 in _PyWeakref_ClearRef (self=self@entry=0x7f0a9a171df0) at Objects/weakrefobject.c:102
#2 0x0000557c366ec77e in handle_weakrefs (unreachable=unreachable@entry=0x7ffeec923ad0,
old=old@entry=0x557c36a40f68 <_PyRuntime+76552>) at Modules/gcmodule.c:804
#3 0x0000557c366ecad3 in gc_collect_main (tstate=0x557c36a9e7b0 <_PyRuntime+459600>, generation=generation@entry=2,
n_collected=n_collected@entry=0x0, n_uncollectable=n_uncollectable@entry=0x0, nofail=nofail@entry=1) at Modules/gcmodule.c:1284
#4 0x0000557c366ed333 in _PyGC_CollectNoFail (tstate=tstate@entry=0x557c36a9e7b0 <_PyRuntime+459600>) at Modules/gcmodule.c:2135
#5 0x0000557c366c39bb in finalize_modules (tstate=tstate@entry=0x557c36a9e7b0 <_PyRuntime+459600>) at Python/pylifecycle.c:1602
#6 0x0000557c366c524e in Py_FinalizeEx () at Python/pylifecycle.c:1863
#7 0x0000557c366eb4f9 in Py_RunMain () at Modules/main.c:691
#8 0x0000557c366eb56e in pymain_main (args=args@entry=0x7ffeec923c10) at Modules/main.c:719
#9 0x0000557c366eb63d in Py_BytesMain (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:743
#10 0x0000557c3655979e in main (argc=<optimized out>, argv=<optimized out>) at ./Programs/python.c:15
(gdb) p self
$1 = (PyWeakReference *) 0x7f0a9a171df0
(gdb) p *self
$2 = {ob_base = {{ob_refcnt = 1, ob_refcnt_split = {1, 0}}, ob_type = 0x557c38bda680}, wr_object = 0x7f0a9a171c70, wr_callback = 0x0,
hash = -1, wr_prev = 0x0, wr_next = 0x0, vectorcall = 0x557c3663aa08 <weakref_vectorcall>}
(gdb) p *list
Cannot access memory at address 0xfe15355ba7e0
(gdb) p list
$3 = (PyWeakReference **) 0xfe15355ba7e0
Linked PRs
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
3.12only security fixesonly security fixes3.13only security fixesonly security fixesrelease-blockertopic-typingtype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump
Projects
- StatusShow more project fieldsDone
Activity
Eclips4 commentedon Aug 22, 2023
cc @JelleZijlstra
mgorny commentedon Aug 22, 2023
Oh, and this is also filed at pydantic/pydantic#7181. I'm not really 100% sure whether pydantic isn't doing something wrong that got exposed here.
Eclips4 commentedon Aug 22, 2023
It would be nice if you could provide a pure python code(without pydantic) which crashes =)
mgorny commentedon Aug 22, 2023
I'm afraid that's as far as I managed (reducing it to one test file). Even with that, there are times when I can't reproduce it a single time — and times when it fails all the time. Right now I'm at the former, so I have no clue how to move forward.
immolo commentedon Aug 23, 2023
I've done a few quick tests on a clean system to see what I can find, so far I've found this issue doesn't exist when using 3.12beta4 and below.
I'll add an strace from my system as it seems to failing at the same place for me every time and then see if I can confirm anything more to help solve this.
strace.txt
mgorny commentedon Aug 24, 2023
@immolo, thanks. I've already pointed out the specific commit (58f9c88) where this starts, and strace is unlikely to help.
immolo commentedon Aug 24, 2023
Sorry I worded this poorly @mgorny
I meant this as a I've confirmed what you are seeing post.
mgorny commentedon Aug 26, 2023
Eh, this bug really sucks. All I've been able to establish so far is that — obviously — it's GC-related. If I decrease GC threshold low enough or disable GC, it stops happening. If I reduce the file too much, it stops happening. And ofc it also randomly stops happening independently of that, and FWICS it's not affected by
PYTHONHASHSEED.So far my only guess is that if something is GC-ed too late, it segfaults.
JelleZijlstra commentedon Aug 26, 2023
I suspect we have to call
PyObject_ClearWeakRefs(self)intypevar_deallocafter we call_PyObject_GC_UNTRACK. I haven't tried to repro yet, so I'll do that first and then see if this suggested change makes the issue go away.mgorny commentedon Aug 26, 2023
In the meantime, I managed to produce a segfault when allocating a large
WeakValueDictionarybut I'm not sure if it's the same bug:JelleZijlstra commentedon Aug 26, 2023
That one doesn't repro for me with a freshly built main:
JelleZijlstra commentedon Aug 26, 2023
Oh wait, I had already applied my suggested patch when I tried your repro. Without the patch, it does segfault, which strongly suggests that my patch is right. Thanks for the much smaller repro case!
The repro from the original post doesn't work on main because pydantic-core doesn't build there. I'll build 3.12 when I get a chance, but in the meantime I'll send a PR for the
PyObject_ClearWeakRefschange.7 remaining items
davidhewitt commentedon Aug 26, 2023
That's possibly related to PyO3/pyo3#3064. In general I think it's a reasonable objective for us to support debug builds, but we can't easily test them in CI (actions/setup-python#86)
mgorny commentedon Aug 26, 2023
--with-pydebug? Yeah, I was wondering if it's supposed to be used against other packages, or just to test CPython itself — because so many things failed in pydantic. That's why I used--with-assertionsinstead.JelleZijlstra commentedon Aug 27, 2023
Ideally all C extensions should work in a pydebug build, but that's a bigger project and it sounds like it would also need work in PyO3.
gh-108295: Fix crashes with TypeVar weakrefs (#108517)
pythongh-108295: Fix crashes with TypeVar weakrefs (pythonGH-108517)
[3.12] gh-108295: Fix crashes with TypeVar weakrefs (GH-108517) (#108527
erlend-aasland commentedon Aug 27, 2023
It looks to me that this has been resolved.
davidhewitt commentedon Aug 28, 2023
Thanks, yes I will investigate debug build support in pyo3/ pydantic separately.
fix: add session fixture to force GC before pytest shutdown
try: disable weakref.finalize during pytest to avoid segfault
fix: disable weakref.finalize to prevent GC segfault
ci: fix segfaults in benchmarks (#102)