Skip to content

[Python][FlightRPC] FlightServerBase is never freed, leaking the server and everything it references #50684

Closed

Description

@raulcd

Describe the bug, including details regarding any error messages, version, and platform.

A FlightServerBase, even after shutdown(), wait() and dropping the last user reference, doesn't seem to be completely freed. It stays alive and leaks.

Applications that create a Flight server per unit of work (one per build, per request batch, per test) accumulate one zombie server per cycle.

$ uv run python
Python 3.14.2 (main, Jan 14 2026, 19:38:07) [Clang 21.1.4 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gc
... import pyarrow.flight as fl
... 
... class Server(fl.FlightServerBase):
...     pass
... 
... for _ in range(100):
...     server = Server("grpc://127.0.0.1:0")
...     server.payload = bytearray(8 * 1024 * 1024)
...     server.shutdown()
...     server.wait()
...     del server
...     gc.collect()
... 
... print(sum(1 for o in gc.get_objects() if isinstance(o, Server)))
... 
100
>>> import pyarrow
>>> pyarrow.__version__
'25.0.0'

RSS grows ~8 MB per iteration, tracking the payload one for one. The same loop with a plain Python object instead of a Flight server keeps RSS flat and prints 0.

Without a payload the loop still leaks about 66 kB RSS and 12 to 16 MB of virtual address space per iteration. An equivalent C++ loop creating and shutting down a Flight server shows no growth, so this points at an issue in the Python bindings.

Component(s)

FlightRPC, Python

Activity

  1. self-assigned this
    on Jul 28, 2026
  2. KHARSHAVARDHAN-eng commented on Jul 28, 2026

    @KHARSHAVARDHAN-eng

    hey, this issue looks interesting, can i work on it ??

  3. raulcd commented on Jul 28, 2026

    @raulcd
    MemberAuthor

    Hi @KHARSHAVARDHAN-eng this was already assigned and there was a draft PR opened. You've opened 8 PRs in the last couple of days and we have already commented on some of those. They seem to be opened directly by LLM and they have several issues, could you fix the previous opened PRs instead of working on new ones? Thanks.

  4. added a commit that references this issue on Jul 31, 2026
  5. added this to the 26.0.0 milestone on Jul 31, 2026
  6. raulcd commented on Jul 31, 2026

    @raulcd
    MemberAuthor

    Issue resolved by pull request 50687
    #50687

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions