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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have some flaky issue in CI on the freethreaded Python with
test_traverse_subclassandtest_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: