This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Segfault when using trace functions in 3.11a3
Type: crash Stage:
Components: Interpreter Core Versions: Python 3.11
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Cyril Jouve, Mark.Shannon, Quentin.Pradet, alex, reaperhulk
Priority: normal Keywords:

Created on 2021-12-23 03:07 by reaperhulk, last changed 2022-04-11 14:59 by admin.

Messages (7)
msg409061 - (view) Author: Paul Kehrer (reaperhulk) Date: 2021-12-23 03:07
In Python 3.11a3 on Linux/x86_64 (failed to replicate on macOS, not attempted on Windows) the interpreter non-deterministically segfaults when running some code under coverage. This did not occur under 3.11a2. Looking at the backtrace from a core dump I see:

#0  _PyFrame_FastToLocalsWithError (frame=0x7fedf9e1f608) at Objects/frameobject.c:903
#1  0x00007fedfa15f593 in call_trampoline (tstate=0x55b767a44080, callback=0x7fedf8bbd9c0, 

This is the trace received if I use pure Python coverage (sys.settrace) while I get one inside coverage's ctracer if I use the native library. However, at the moment I don't believe the bug resides within coverage.

Since stack frame optimization has been a focus in 3.11 could something have changed that is causing issues with sys.settrace/PyEval_SetTrace?

I haven't managed to reduce this test case much but here's a somewhat messy dockerfile that can demonstrate it:

FROM ubuntu:focal
RUN apt-get update && apt-get install -y build-essential git cargo libffi-dev libssl-dev libsqlite3-dev zlib1g-dev curl
RUN curl -OL && \
    tar zxf Python-3.11* && \
    cd Python-3.11* && \
    ./configure --prefix=/opt && \
    make -j4 && make install
RUN /opt/bin/pip3 install tox && git clone
RUN cd cryptography && /opt/bin/tox -e py311
msg410385 - (view) Author: Quentin Pradet (Quentin.Pradet) * Date: 2022-01-12 05:46
The ABI between alpha 2 and alpha 3 changed, see If pip built (say) cffi in CI for alpha2 and put it in the cache, then it reused that wheel for alpha3 and the segfault is expected.
msg410817 - (view) Author: Paul Kehrer (reaperhulk) Date: 2022-01-17 18:33
Changes in ABI don't seem to be the likely culprit since the Dockerfile provided can demonstrate this bug and has no caching that would result in obtaining alpha2-based binaries.
msg410842 - (view) Author: Quentin Pradet (Quentin.Pradet) * Date: 2022-01-18 06:42
Thanks, you're right, I ran `git bisect` on Linux and the commit that causes the issue is ("Copy free variables in bytecode to allow calls to inner functions to be specialized") from
msg412733 - (view) Author: Mark Shannon (Mark.Shannon) * (Python committer) Date: 2022-02-07 11:31
Can you reproduce this failure with just Python?
If not, with just cryptography and not tox?
msg412808 - (view) Author: Alex Gaynor (alex) * (Python committer) Date: 2022-02-08 04:09
It seems to no longer be crashing with alpha5. Hopefully it's actually fixed and not merely having a more subtle failure mode.
msg412863 - (view) Author: Cyril Jouve (Cyril Jouve) * Date: 2022-02-08 19:49
this looks related to / related to binary incompatibility in coverage (6.2) binary wheel built with 3.11alpha2 and running on 3.11alpha3 or later.

Latest release of coverage (6.3) do not ship binary wheel for python 3.11 anymore, so it's installed and built with your current python.
Date User Action Args
2022-04-11 14:59:53adminsetgithub: 90317
2022-02-08 19:49:23Cyril Jouvesetnosy: + Cyril Jouve
messages: + msg412863
2022-02-08 04:09:47alexsetmessages: + msg412808
2022-02-07 11:31:50Mark.Shannonsetmessages: + msg412733
2022-01-18 06:42:14Quentin.Pradetsetmessages: + msg410842
2022-01-17 18:33:06reaperhulksetmessages: + msg410817
2022-01-12 05:46:47Quentin.Pradetsetnosy: + Quentin.Pradet
messages: + msg410385
2021-12-23 03:11:18alexsetnosy: + alex, Mark.Shannon
components: + Interpreter Core
2021-12-23 03:07:56reaperhulksettitle: Segfault -> Segfault when using trace functions in 3.11a3
2021-12-23 03:07:26reaperhulkcreate