Skip to content

libmpv: file descriptor leak (fence) with GL renderer #17217

@NathaanTFM

Description

@NathaanTFM

mpv Information

mpv v0.41.0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Jan  2 2026 11:48:22
libplacebo version: v7.358.0 (v7.351.0-106-gbc90ef94)
FFmpeg version: N-122322-gee5d6e7ee1
FFmpeg library versions:
   libavcodec      62.23.102
   libavdevice     62.2.100
   libavfilter     11.10.101
   libavformat     62.8.102
   libavutil       60.21.102
   libswresample   6.2.100
   libswscale      9.3.100

Other Information

- Kernel Version: 6.12.47+rpt-rpi-v8
- GPU Model: vc4drmfb (Raspberry Pi 4B)
- Mesa/GPU Driver Version: 3.1 Mesa 24.2.8-1~bpo12+rpt4
- Window Manager and Version: none (using startx)
- Source of mpv: built 0.41.0 (mpv-build), also happens on trixie upstream
- Latest known working version: 0.36.1 (not tested after)
- Issue started after the following happened: n/a

Reproduction Steps

This issue happens with the v3d / vc4 MESA driver on RPi 4B. It probably does not happen with vulkan.

This issue can be produced with any libmpv GL renderer. It has been tested with a custom software (that is not using the "advanced mode") and with a demo sample.

Run the sample, and it will work for quite some time, but the file descriptors will keep increasing (never closed) until the program stops working (but does NOT crash).

Expected Behavior

Sample program just works and play a video file.

Actual Behavior

Sample program works for quite some time, then "export failed" spams in the console and the render is broken.

Log File

Backtrace of when the error is called (then drmSyncobjExportSyncFile prints "export failed")

(gdb) bt
#0  0x0000007fac89b830 in drmSyncobjExportSyncFile () from /lib/aarch64-linux-gnu/libdrm.so.2
#1  0x0000007fad93e5b4 in ?? () from /lib/aarch64-linux-gnu/libgallium-24.2.8-1~bpo12+rpt4.so
#2  0x0000007faccef12c in ?? () from /lib/aarch64-linux-gnu/libgallium-24.2.8-1~bpo12+rpt4.so
#3  0x0000007fb32a9088 in ra_gl_ctx_submit_frame () from ./libmpv.so.2
#4  0x0000007fb32a99c8 in done_frame () from ./libmpv.so.2
#5  0x0000007fb326f544 in render () from ./libmpv.so.2
#6  0x0000007fb328a178 in mpv_render_context_render () from ./libmpv.so.2
#7  0x00000055710c2ad0 in main (argc=<optimized out>, argv=<optimized out>) at player_mpv.c:527

I cannot produce a log file without recompiling the lib, but I can give you the cause of the problem instead. Sorry about that. I hope that the technical details make up for the missing log file.

The func ra_gl_ctx_submit_frame calls gl->FenceSync which allocates a fence (fd), appends it to p->vsync_fences and then the fence is closed by ra_gl_ctx_swap_buffers.

The libmpv output with GL renderer does not call swap_buffers and never closes the fence, which causes an important fd leak on v3d/vc4 MESA driver (using RPi 4B).

This has been tested on upstream RPi trixie (64-bit), and on bookworm with a custom built v0.41.0. Faulty code is still in master. Removing the gl->FenceSync call fixes the problem, but is not an acceptable solution (which is why I am creating an issue instead of a PR).

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

  • I tested with the latest mpv version to validate that the issue is not already fixed.
  • I provided all required information including system and mpv version.
  • I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
  • I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
  • I attached the full, untruncated log file.
  • I attached the backtrace in the case of a crash.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions