Skip to content

Massive Xorg memory leak pointing to iris_dri

System information

Please post inxi -GSC -xx output (fenced with triple backticks) OR fill information below manually

System:
  Host: bat.mindbit.ro Kernel: 5.15.14-200.fc35.x86_64 x86_64 bits: 64
    compiler: gcc v: 2.37-10.fc35 Desktop: MATE 1.26.0 wm: marco
    dm: GDM, LightDM Distro: Fedora release 35 (Thirty Five)
CPU:
  Info: dual core model: Intel Core i5-5200U bits: 64 type: MT MCP
    arch: Broadwell rev: 4 cache: L1: 128 KiB L2: 512 KiB L3: 3 MiB
  Speed (MHz): avg: 1932 high: 2020 min/max: 500/2700 cores: 1: 1989
    2: 1989 3: 2020 4: 1733 bogomips: 17557
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: Intel HD Graphics 5500 vendor: Lenovo driver: i915 v: kernel
    bus-ID: 00:02.0 chip-ID: 8086:1616
  Device-2: Acer Integrated Camera type: USB driver: uvcvideo bus-ID: 2-8:7
    chip-ID: 5986:0366
  Display: server: X.Org 1.20.14 compositor: marco driver:
    loaded: modesetting unloaded: fbdev,vesa resolution: 1: 1366x768~60Hz
    2: 1920x1080 s-dpi: 96
  OpenGL: renderer: Mesa Intel HD Graphics 5500 (BDW GT2)
    v: 4.6 Mesa 21.3.5 direct render: Yes

Describe the issue

I'm seeing a massive memory leak in the Xorg process. I believe this is not another instance of an X resource leak, for the following reasons:

  • The leak occurs only when running bare metal on my laptop. I'm running the same environment (same Fedora version, same set of applications) in a virtualbox VM and in a qemu-kvm VM, and the leak does not occur.
  • The xrestop program shows no increase of allocated resources, even though the Xorg process leaks memory at the same time.

Regression

This is not something new, it's been going on for almost three years, but I didn't have the time to look closer into it until recently. I'm pretty sure I've been seeing it since day 1 of using my current laptop, so it could be triggered on this particular hardware. I can't remember if I saw it on the laptop I previously used (and I no longer have it, so I can't check).

Any extra information would be greatly appreciated

I used a simple malloc/calloc/realloc wrapper that I wrote myself, and found two spots where a large amount of memory is leaked. Statistics below are based on data that was gathered within just a few minutes of running Xorg.

691136 bytes in 5400 occurrences of:
calloc + 130 in section .text of /usr/local/lib64/libdebugalloc.so
iris_create_surface + 795 in section .text of /usr/lib64/dri/iris_dri.so
tc_create_surface + 24 in section .text of /usr/lib64/dri/iris_dri.so
st_update_renderbuffer_surface + 528 in section .text of /usr/lib64/dri/iris_dri.so
st_render_texture + 153 in section .text of /usr/lib64/dri/iris_dri.so
_mesa_framebuffer_texture + 320 in section .text of /usr/lib64/dri/iris_dri.so
_mesa_FramebufferTexture2D + 46 in section .text of /usr/lib64/dri/iris_dri.so
glamor_pixmap_ensure_fb.lto_priv + 136 in section .text of /usr/lib64/xorg/modules/libglamoregl.so
glamor_create_fbo + 123 in section .text of /usr/lib64/xorg/modules/libglamoregl.so
glamor_create_pixmap + 1128 in section .text of /usr/lib64/xorg/modules/libglamoregl.so
ProcCreatePixmap + 254 in section .text of /usr/libexec/Xorg.real
main + 3095 in section .text of /usr/libexec/Xorg.real
__libc_start_call_main + 128 in section .text of /lib64/libc.so.6
__libc_start_main_impl + 124 in section .text of /lib64/libc.so.6
_start + 37 in section .text of /usr/libexec/Xorg.real
198560 bytes in 6205 occurrences of:
realloc + 213 in section .text of /usr/local/lib64/libdebugalloc.so
_iris_batch_flush + 1642 in section .text of /usr/lib64/dri/iris_dri.so
iris_fence_flush + 153 in section .text of /usr/lib64/dri/iris_dri.so
st_glFlush + 55 in section .text of /usr/lib64/dri/iris_dri.so
_glamor_block_handler + 100 in section .text of /usr/lib64/xorg/modules/libglamoregl.so
msBlockHandler + 55 in section .text of /usr/lib64/xorg/modules/drivers/modesetting_drv.so
BlockHandler + 164 in section .text of /usr/libexec/Xorg.real
WaitForSomething + 338 in section .text of /usr/libexec/Xorg.real
main + 1277 in section .text of /usr/libexec/Xorg.real
__libc_start_call_main + 128 in section .text of /lib64/libc.so.6
__libc_start_main_impl + 124 in section .text of /lib64/libc.so.6
_start + 37 in section .text of /usr/libexec/Xorg.real

Both stack traces point to iris_dri.so. However, this may be a leak in libglamoregl.so, since that's what calls into iris_dri.so in both cases. That would make it an Xorg bug instead.

For what is worth, I checked the Xorg log, and iris_dri.so is not used in either of the VM environments I mentioned before (where the leak does not occur). In fact, no DRI is used at all in those environments.

I am not familiar with the mesa (or Xorg) code base, however I am a fairly experienced C programmer, so I can help debug this further and narrow down the problem.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information