New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
trio segfaults on import when using CPython 3.12.0b4 on Windows #2714
Comments
Just realised that trio is pure-python, Did a little more digging, it appears to be when cffi loads a library. Tracked it down to this line: Lines 53 to 57 in a9a9170
Specifically, I also tried with cffi installed from the development branch ( my debug scriptI'll keep this here in case it's useful later too. import sys
depth = 0
def trace(frame, event, what):
if event not in ('call', 'return'): return
direction = 1 if event == 'call' else -1
global depth
depth += direction
path = frame.f_code.co_filename
if '\\cffi\\' in path: return
if '\\pycparser\\' in path: return
if '<frozen' in path: return
if 'Python312\\Lib\\' in path: return
if '_distutils_hack' in path: return
frame_desc = f"{frame.f_code.co_name} {frame.f_code.co_filename}:{frame.f_code.co_firstlineno}"
inout = " -->" if event == 'call' else "+ <--"
print(f"{'+'*depth}{inout} {frame_desc}")
sys.setprofile(trace)
import trio This produced huge amounts of output, ending in-
I saw that the last call was to the trio\_util.py module, which led me to that line. I had to hide a few libraries as shown in the code to reduce the noise. |
This looks like a cffi issue, not ours. |
Hello! I'm closing this since this is an upstream issue. Here's some stuff:
Edit: here's a more complete stack trace: |
Err, actually, the comment directly above the line in question does say we could replace with |
That line could use ctypes, but the rest of trio uses cffi heavily on
windows, so if cffi is broken in general then changing that line won't help.
…On Sat, Jul 29, 2023, 18:07 EXPLOSION ***@***.***> wrote:
Err, actually, the comment directly above the line in question does say we
could replace with ctypes. That might be worth it for future stability...
—
Reply to this email directly, view it on GitHub
<#2714 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEU42CSMJNU33EUBACMPETXSWXUJANCNFSM6AAAAAA2UNNMNQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Have you checked whether the issue still occurs when building and installing cffi from the latest commit of their They currently can't or don't want to publish a new release because of some py312 issues. Some issues were fixed recently, and one of the open issues is this one here, referring to the comment made by @A5rocks. I just built cffi in my Windows VM and ran the trio tests. I had two test failures, but those were unrelated. When installing cffi 1.15.1 from PyPI however, the Python 3.12 interpreter crashed. Please have a look at this and report back to the cffi issue tracker if those crashes are indeed gone. /c/Python312/python -m venv ~/venv/trio
source ~/venv/trio/Script/activate
python -m pip install -U pip build wheel
git clone https://github.com/python-trio/trio
hg clone https://foss.heptapod.net/pypy/cffi
cd cffi
python -m build --outdir dist --wheel
cd ../trio
python -m pip install -U -r test-requirements.txt
python -m pip install -U --force-reinstall ../cffi/dist/cffi-*.whl
python -m pytest -r a -p trio._tests.pytest_plugin |
I'll check in a while but I suspect you're right -- I don't remember installing from source last time (heck, I don't think I even have mercurial on this computer!!). You might want to comment on the cffi issue yourself since I may forget to do this for a while! |
I don't have an account there and this banner is shown:
Please just post a quick comment since you're already registered. Thank you. |
Alright, done! |
The test suite for pyinstrument picks up trio, so I noticed this error.
In short, trio segfaults on import on this platform:
The process just crashed. Running with faulthandler,
Frustratingly, the faulthandler crashes when trying to print the stack trace, so it's not possible to see where it was when it crashed.
I'm using the Python.org distribution of CPython 3.12.0b4, on an AMD64 machine.
The text was updated successfully, but these errors were encountered: