Skip to content

Intermittent failure in test_unix_pipes::test_del on pypy #1277

@njsmith

Description

@njsmith

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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions