Repository navigation
muffin leaks (interns unbound number of) atoms #816
Description
Activity
Diagnosis confirmed at
src/x11/meta-x11-selection-input-stream.c:529—g_strdup_printf ("META_SELECTION_%p", stream)plusXInternAtomdoes indeed leak one atom per stream, since X has noDeleteAtomoperation._finalize()frees the C string but the server-side atom is immortal.Upstream mutter fixed this in April 2021 via MR 1812, which muffin missed by ~12 months when it forked from mutter 3.36. Two coordinated commits:
dbd6e74d"x11: Let selection input streams create their own window" — gives each stream its ownInputOnlyoverride_redirectwindow, also fixes a correctness bug where concurrentXConvertSelectionrequests on the same window could lose data986d3043"x11: Avoid memory waste and work when creating selection input stream" — since each stream now has its own window, the property name no longer needs to be unique, soMETA_SELECTION_%pbecomes a single fixedMETA_SELECTION. Explicitly addresses the atom leak: "creates a new atom for every transfer since those are never freed, neither on the shell nor on the server side". Fixes mutter#1328.
Plus a small prep commit
d25175b9from the same MR. The set is self-contained to that file and looks straightforward to backport.
Distribution
Mint 22.3
Package version
6.6.7
Graphics hardware in use
AMD Radeon 860M
Frequency
Always
Bug description
libmuffin 6.6.3+zena
muffin is interning an unbounded number of X11 atoms. E.g.
and after selecting the above text to paste it here, the number is now at 196. Each new selection creates a new atom.
This is probably
meta_x11_selection_input_stream_new_async()interning a new"META_SELECTION_%p"atom each time it's called.Steps to reproduce
select some text. repeat the above command and see the number grows.
Expected behavior
Atoms are not leaked
Additional information
No response