-
Notifications
You must be signed in to change notification settings - Fork 243
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
Segmentation faults — tracking issue #451
Comments
PyO3/pyo3#2781 is also relevant. |
getting this lots more on #465, seems to be happening every time. |
Okay, I've tried to investigate this, but I'm not finding much. Steps I took, added - uses: mxschmitt/action-tmate@v3
if: failure() To
To try and get symbol information, I changed Again segfault, followed the above, but still no useful information from gdb, here's the output:
I really don't know where to go from here - on #465 the coverage run seg faults every time, runs without @messense @davidhewitt would love your help on this one. Any ideas? |
I just tried but I'm unable to reproduce the segfault with |
While trying to debug with
|
Got a Python traceback after it crashes (but there are no symbols in coredump file)
|
Finally got a backtrace in C!
|
This is amazing, thank you so much. Next question - any idea what's actually causing this error? I'm still unclear on how to dig deeper. Also, I'd love to know what you did to get this traceback. |
Not sure yet, still digging, that error might not be the root cause of the crash when
apt install python3.11-dbg
python3.11-dbg -m venv .venv sets up a venv with debug build of Python, install gdb --args .venv/bin/python -m coverage run -m pytest -k test_tz_comparison |
Ahh, now I got a backtrace of LLVM related code crashing with normal Python build
I think this might indicate that the crash is caused by LLVM failed to write out the |
Great, very good to know this really does relate to writing coverage files. Any idea why the Also really weird that it's started happening every time on #465 although that PR doesn't touch or test any of that code. |
No idea yet, maybe fix the |
Reported the |
Thanks, I did a bit of digging and the resource warning happens everywhere, so I don't think that's the cause of the seg fault. |
Further digging, I tried:
In both cases we still get the seg fault 😞. See #477. |
Since the segfault happens in LLVM, IMO it's better to debug it with a debug build of Rust and report to Rust or LLVM project. Though it might be hard to narrow it down to a minimal repro. |
Honestly, I've tried pretty hard to reproduce this locally, but can't. How did you get the seg fault to happen locally? |
I'm simply using a normal Python 3.11 with the following commands running at the root of the project. ulimit -c unlimited
python3.11 -m venv .venv
.venv/bin/pip install -r tests/requirements.txt
RUSTFLAGS="-g -C instrument-coverage" maturin develop --release
gdb --args .venv/bin/python -m coverage run -m pytest -k test_tz_comparison and |
BTW, remove Line 63 in 40b72a3
|
I'm afraid I still can't reproduce the failure locally on either macos or ubuntu. |
so turns out we don't get the seg fault on either macos or ubuntu-20.04, so I've switched to 20.04 for coverage for now as I don't have time to debug this further. |
Haven't had this issue in forever so I'm going to close this now. |
I recreate this issue with Ubuntu 22, Windows/WSL and Docker ubuntu:latest by creating a Python==3.12 | 3.11 | 3.10 Commands and returns without datetime module
After renaming the folder
Return from
|
@SrGitQ can you please open that as a new issue with a full repro of instructions how to observe this (including the source code)? I would be happy to investigate. |
I'm creating this issue to track segmentation fault issues that we have run into while working on pydantic or pydantic-core.
Obviously it is a major problem if users are at risk of hitting segmentation faults thanks to using pydantic. So far it seems that when we've hit segmentation faults during development, other potential culprits have been at least tangentially involved, but we should keep an eye out for patterns in case there is anything we can do to minimize the potential for this.
Some cases where we've had segmentation faults:
pydantic
-internal code has caused a segfault to occur until I moved the debug point/points. (Usually I can get to the line I wanted to break by moving the debug point appropriately and manually stepping, but not always.)Please add comments on this issue if you run into any new sources of segmentation fault, or discover new patterns in their occurrence, so we can investigate and resolve any issues.
The text was updated successfully, but these errors were encountered: