Segmentation fault in 3.11.4, 3.12.0b3; _PyInterpreterFrame ownership issue #106092
Labels
3.11
only security fixes
3.12
bugs and security fixes
type-crash
A hard crash of the interpreter, possibly with a core dump
Comments
andersk
added
the
type-crash
alexmv
added a commit
to alexmv/zulip
that referenced
this issue
Jun 26, 2023
Having exactly 17 middlewares, on Python 3.11.0 and above, causes python to segfault when running tests with coverage; see python/cpython#106092 Work around this by adding a no-op middleware if we would hit that unlucky number. We only add it in testing, since coverage is a requirement to trigger it, and there is no reason to burden production with an additional wrapping.
alexmv
added a commit
to alexmv/zulip
that referenced
this issue
Jun 26, 2023
Having exactly 17 or 18 middlewares, on Python 3.11.0 and above, causes python to segfault when running tests with coverage; see python/cpython#106092 Work around this by adding a no-op middleware if we would hit that unlucky number. We only add it in testing, since coverage is a requirement to trigger it, and there is no reason to burden production with an additional wrapping.
|
I think I understand the problem.
Lines 128 to 137 in f992a60 However, that is not the only reason the Cc @markshannon (GH-27077). |
alexmv
added a commit
to alexmv/zulip
that referenced
this issue
Jun 28, 2023
Having exactly 17 or 18 middlewares, on Python 3.11.0 and above, causes python to segfault when running tests with coverage; see python/cpython#106092 Work around this by adding a no-op middleware if we would hit that unlucky number. We only add it in testing, since coverage is a requirement to trigger it, and there is no reason to burden production with an additional wrapping.
alexmv
added a commit
to alexmv/zulip
that referenced
this issue
Jun 28, 2023
Having exactly 17 or 18 middlewares, on Python 3.11.0 and above, causes python to segfault when running tests with coverage; see python/cpython#106092 Work around this by adding one or two no-op middlewares if we would hit those unlucky numbers. We only add them in testing, since coverage is a requirement to trigger it, and there is no reason to burden production with additional wrapping.
timabbott
pushed a commit
to zulip/zulip
that referenced
this issue
Jul 2, 2023
Having exactly 17 or 18 middlewares, on Python 3.11.0 and above, causes python to segfault when running tests with coverage; see python/cpython#106092 Work around this by adding one or two no-op middlewares if we would hit those unlucky numbers. We only add them in testing, since coverage is a requirement to trigger it, and there is no reason to burden production with additional wrapping.
alexmv
added a commit
to alexmv/zulip
that referenced
this issue
Jul 3, 2023
Having exactly 17 or 18 middlewares, on Python 3.11.0 and above, causes python to segfault when running tests with coverage; see python/cpython#106092 Work around this by adding one or two no-op middlewares if we would hit those unlucky numbers. We only add them in testing, since coverage is a requirement to trigger it, and there is no reason to burden production with additional wrapping. (cherry picked from commit cf0b803)
beniwohli
added a commit
to beniwohli/apm-agent-python
that referenced
this issue
Jul 10, 2023
currently fails with a segmentation fault. Could be related to python/cpython#106092
andersk
added a commit
to andersk/cpython
that referenced
this issue
Jul 18, 2023
It was possible for the trashcan to delay the deallocation of a PyFrameObject until after its corresponding _PyInterpreterFrame has already been freed. So frame_dealloc needs to avoid dereferencing the f_frame pointer unless it first checks that the pointer still points to valid memory. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
andersk
added a commit
to andersk/cpython
that referenced
this issue
Jul 18, 2023
It was possible for the trashcan to delay the deallocation of a PyFrameObject until after its corresponding _PyInterpreterFrame has already been freed. So frame_dealloc needs to avoid dereferencing the f_frame pointer unless it first checks that the pointer still points to valid memory. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
markshannon
pushed a commit
that referenced
this issue
Aug 1, 2023
It was possible for the trashcan to delay the deallocation of a PyFrameObject until after its corresponding _PyInterpreterFrame has already been freed. So frame_dealloc needs to avoid dereferencing the f_frame pointer unless it first checks that the pointer still points to the interpreter frame within the frame object. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
This was referenced Aug 1, 2023
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
Aug 1, 2023
…106875) It was possible for the trashcan to delay the deallocation of a PyFrameObject until after its corresponding _PyInterpreterFrame has already been freed. So frame_dealloc needs to avoid dereferencing the f_frame pointer unless it first checks that the pointer still points to the interpreter frame within the frame object. (cherry picked from commit 557b05c) Co-authored-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Anders Kaseorg <andersk@mit.edu>
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
Aug 1, 2023
…106875) It was possible for the trashcan to delay the deallocation of a PyFrameObject until after its corresponding _PyInterpreterFrame has already been freed. So frame_dealloc needs to avoid dereferencing the f_frame pointer unless it first checks that the pointer still points to the interpreter frame within the frame object. (cherry picked from commit 557b05c) Co-authored-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Anders Kaseorg <andersk@mit.edu>
pablogsal
pushed a commit
that referenced
this issue
Aug 1, 2023
Yhg1s
pushed a commit
that referenced
this issue
Aug 1, 2023
… (#107532) gh-106092: Fix use-after-free crash in frame_dealloc (GH-106875) It was possible for the trashcan to delay the deallocation of a PyFrameObject until after its corresponding _PyInterpreterFrame has already been freed. So frame_dealloc needs to avoid dereferencing the f_frame pointer unless it first checks that the pointer still points to the interpreter frame within the frame object. (cherry picked from commit 557b05c) Signed-off-by: Anders Kaseorg <andersk@mit.edu> Co-authored-by: Anders Kaseorg <andersk@mit.edu>
basepi
added a commit
to elastic/apm-agent-python
that referenced
this issue
Aug 24, 2023
currently fails with a segmentation fault. Could be related to python/cpython#106092 Co-authored-by: Colton Myers <colton@basepi.net>
andersk
added a commit
to andersk/zulip
that referenced
this issue
Feb 2, 2024
This is probably a more effective workaround for python/cpython#106092. Signed-off-by: Anders Kaseorg <anders@zulip.com>
andersk
added a commit
to zulip/zulip
that referenced
this issue
Feb 6, 2024
This is probably a more effective workaround for python/cpython#106092. Signed-off-by: Anders Kaseorg <anders@zulip.com>
amaranand360
pushed a commit
to amaranand360/zulip
that referenced
this issue
Feb 17, 2024
This is probably a more effective workaround for python/cpython#106092. Signed-off-by: Anders Kaseorg <anders@zulip.com>
mananbordia
pushed a commit
to mananbordia/zulip
that referenced
this issue
Feb 27, 2024
This is probably a more effective workaround for python/cpython#106092. Signed-off-by: Anders Kaseorg <anders@zulip.com>
andersk
added a commit
to andersk/zulip
that referenced
this issue
Mar 7, 2024
This is probably a more effective workaround for python/cpython#106092. Signed-off-by: Anders Kaseorg <anders@zulip.com> (cherry picked from commit 4f27381)
timabbott
pushed a commit
to zulip/zulip
that referenced
this issue
Mar 7, 2024
This is probably a more effective workaround for python/cpython#106092. Signed-off-by: Anders Kaseorg <anders@zulip.com> (cherry picked from commit 4f27381)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Crash report
This test case (minimized from a crash in the Zulip test suite) causes a segmentation fault in Python 3.11.4 and 3.12.0b3.
https://github.com/andersk/python-segfault
Based on the tracebacks below, this looks like a
_PyInterpreterFrameownership issue similar to #99729 and #100126. The crash is here:cpython/Objects/frameobject.c
Line 854 in 1bbf60d
where the
_PyInterpreterFrameat*f->f_framehas already been freed.Error messages
Full output with Python traceback
AddressSanitizer traceback
This is from the current
3.11branch, commit 1bbf60d.Your environment
Linked PRs
The text was updated successfully, but these errors were encountered: