Repository navigation
Intermittent failure in test_unix_pipes::test_del on pypy #1277
Description
From https://travis-ci.org/python-trio/trio/jobs/603748875:
___________________________________ test_del ___________________________________
async def test_del():
w, r = await make_pipe()
f1, f2 = w.fileno(), r.fileno()
del w, r
gc_collect_harder()
with pytest.raises(OSError) as excinfo:
> os.close(f1)
E Failed: DID NOT RAISE <class 'OSError'>
../../../../virtualenv/pypy3.6-7.1.1/site-packages/trio/tests/test_unix_pipes.py:112: Failed
----------------------------- Captured stderr call -----------------------------
Exception ignored in: <socket.socket fd=27, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=6, laddr=('127.0.0.1', 47668), raddr=('127.0.0.1', 39833)>
ResourceWarning: unclosed <socket.socket fd=27, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=6, laddr=('127.0.0.1', 47668), raddr=('127.0.0.1', 39833)>
Not sure what's going on here... gc_collect_harder runs gc.collect() four times, which I thought was about twice as many times as we needed to make sure that all destructors ran.
I guess we could probably hack this test to directly call __del__ instead of relying on the GC, but we have other tests that rely on gc_collect_harder that would be harder to fix (e.g. because they're checking interactions with the coroutine __del__ method built into the interpreter).
Activity
A5rocks commentedon Mar 22, 2025
Well this doesn't seem to fail anymore.