-
Notifications
You must be signed in to change notification settings - Fork 753
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
subclass + GC is flaky on free-threaded build #4627
Comments
Here's a weird thing. If I make the following modification: diff --git a/tests/test_gc.rs b/tests/test_gc.rs
index 9483819c..e78755d3 100644
--- a/tests/test_gc.rs
+++ b/tests/test_gc.rs
@@ -66,7 +66,7 @@ impl DropCheck {
#[track_caller]
fn assert_drops_with_gc(&self, object: *mut pyo3::ffi::PyObject) {
// running the GC might take a few cycles to collect an object
- for _ in 0..100 {
+ for i in 0..100 {
if self.0.is_completed() {
return;
}
@@ -77,6 +77,9 @@ impl DropCheck {
});
#[cfg(Py_GIL_DISABLED)]
{
+ if i == 99 {
+ dbg!("hello!");
+ }
// on the free-threaded build, the GC might be running in a se>
// some time for this
std::thread::sleep(std::time::Duration::from_millis(5));
@@ -627,12 +630,9 @@ fn test_traverse_subclass() {
check.assert_not_dropped();
}
- #[cfg(not(Py_GIL_DISABLED))]
- {
- // FIXME: seems like a bug that this is flaky on the free-threaded>
- // https://github.com/PyO3/pyo3/issues/4627
- check.assert_drops_with_gc(ptr);
- }
+ // FIXME: seems like a bug that this is flaky on the free-threaded bui>
+ // https://github.com/PyO3/pyo3/issues/4627
+ check.assert_drops_with_gc(ptr); And then if I put a breakpoint in the Here are the stack traces, the main thread is parked and the only worker thread is stuck waiting for drop to be called:
If I break on the first or second sleep, I get a much more reasonable stack trace where multiple worker threads are still running. |
Created an upstream bug, hopefully one of the CPython devs can help us figure out if this is a PyO3 or CPython bug. |
The upstream issue is fixed so we can close this and remove the fixme comments once 3.13.1 comes out. We should also maybe look closely at the other skipped asserts since they might have also been caused by GC corruption. |
We have some flaky issue in CI on the freethreaded Python with
test_traverse_subclass
andtest_traverse_subclass_override_clear
:I can reproduce this locally (with a freethreaded Python):
It seems to be the case that the combination of PyO3 inheritance and freethreaded Python and GC has a subtle edge case. Needs further investigation. I spent some time looking at this today, but I didn't come to a clear conclusion.
I think it's a rare case, it only affects subclassing on the freethreaded build, and I think the resulting issue is just a memory leak. I think therefore it's fine to not block the 0.23 release on this and to instead investigate later.
The text was updated successfully, but these errors were encountered: