1702394 - Mesa memory leaks when drivers are loaded/unloaded

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

When we create a GL context, Mesa loads a library depending on the hardware (or absence of hardware) in use. Currently with EGL, and soon with GLX (see bug 1635451 comment #49), we'll also unload that library by closing the display. So, if that library leaks heap memory, even a small constant amount, then we could potentially use unbounded memory by repeatedly loading/unloading, although in practice this may not be a problem: we'd need on the order of a million cycles of creating a WebGL context and then GCing it (with no other contexts existing in the same process) for it to be significant.

But also, when Leak Sanitizer is in use, it will notice those allocations (since the globals that referenced them no longer exist), and fail to unwind the stack that allocated them (since the library is no longer loaded), meaning we'll fail CI runs with leaks from <unknown module> that can't be suppressed.

I've found two such leaks:

1. r600_dri.so leaks a C++ streambuf instance, allocated in a static constructor for r600::SfnLog. However, I observe that that library and many others (including swrast_dri.so) are hardlinks to the same file, with soname libgallium_dri.so, so using any of those devices (or software, as in the CI runs) triggers the leak.

2. rtasm_exec_malloc → init_heap → u_mmInit leaks some small allocations to manage memory areas; I've observed this with swrast_dri but not radeonsi_dri.

I can report these upstream, but in the short term we'll need a workaround, at least for our CI environment. One approach is to leak a reference to the loaded library (using dl_iterate_phdr to find its full path and then dlopening it) so that it's never unloaded. Doing that where the filename is swrast_dri.so is enough to fix the automated tests.

Comment 1

[Chris Peterson [:cpeterson]]

Tentatively tracking this bug for Fission M8 since it blocks M8 bug 1635451 ("Limit number of client connections to X for fission").

Comment 2

[Neha Kochar [:neha]]

Limit X connections is for Linux enabling for Fission in Beta.

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Bug 1702394 - Work around small memory leaks in Mesa drivers.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d234bef3d1e7
Work around small memory leaks in Mesa drivers. r=jgilbert

Comment 5

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/d234bef3d1e7