Bug 26708

Summary:

libdrm-intel leaks memory when resizing window

Product:

DRI

Reporter:

Lars S <penma.bfdo>

Component:

libdrm

Assignee:

Default DRI bug account <dri-devel>

Status:

RESOLVED MOVED

QA Contact:

Severity:

normal

Priority:

medium

CC:

kontakt, shuang.he

Version:

unspecified

Hardware:

Other

OS:

All

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
full valgrind output of a test run	none
extensive valgrind logfile	none
test.c	none
valgrind of the application without resizing it	none

Description Lars S 2010-02-22 13:47:24 UTC

At least the DRM/Intel module continues to suck up memory just by resizing the window. This would be acceptable behaviour if it wouldn't continue to grow on and on, as it happens for software rendering.

This can not only be reproduced with a (potentially buggy) selfwritten test program but also with the glxdemo.c program from Mesa.

To reproduce, start the test program and make the window smaller, and larger, and smaller again quite wildly and often (10-30 seconds or so).

What happens if you start it with LIBGL_ALWAYS_SOFTWARE=1: Memory usage goes up to about 10M and stays there.

What happens if you start it without that option set (DRM/Intel): Memory usage continues to grow with every resize operation even when the window size is only changed around 100x100 +-5px.

Excerpt from Valgrind output (it had lots of those):

 ==11088== 3,244,032 bytes in 99 blocks are still reachable in loss record 331 of 331
 ==11088==    at 0x4C221A7: malloc (vg_replace_malloc.c:195)
 ==11088==    by 0x7B3A822: ??? (in /usr/lib/libdrm_intel.so.1.0.0)
 ==11088==    by 0x74B2344: ??? (in /usr/lib/dri/i965_dri.so)
 ==11088==    by 0x74B41AD: brw_validate_state (in /usr/lib/dri/i965_dri.so)
 ==11088==    by 0x74A6DBD: brw_draw_prims (in /usr/lib/dri/i965_dri.so)
 ==11088==    by 0x75641A4: vbo_exec_vtx_flush (in /usr/lib/dri/i965_dri.so)
 ==11088==    by 0x7560154: vbo_exec_FlushVertices_internal (in /usr/lib/dri/i965_dri.so)
 ==11088==    by 0x7560221: vbo_exec_FlushVertices (in /usr/lib/dri/i965_dri.so)
 ==11088==    by 0x74DB15D: _mesa_Flush (in /usr/lib/dri/i965_dri.so)
 ==11088==    by 0x4E4C2B1: glXSwapBuffers (in /usr/lib/libGL.so.1.2)

One test run got 23 MiB of still accessible memory all from libdrm. I don't think it's used for anything useful, if not because of the size, then because of the fact the software renderer does not leak.

Comment 1 Lars S 2010-02-23 23:51:32 UTC

Created attachment 33521 [details]
full valgrind output of a test run

For completeness I have attached a more complete Valgrind output file of a test run with the glxdemo program.

Comment 2 Sundtek 2010-02-24 06:44:45 UTC

We also experience the same bug with Intel, our application works well with NVidia though.

Comment 3 Sundtek 2010-02-24 08:28:48 UTC

Created attachment 33527 [details]
extensive valgrind logfile

The memory leak only happens during the application runtime, when deinitialization functions are called all the memory is cleaned up and no memleak occures.
The attached valgrind output shows up all debug symbols.
We ran a sample application (test.c which we will attach right after this post) and interrupted it with ctrl-c before deinitialization.

Comment 4 Sundtek 2010-02-24 08:29:17 UTC

Created attachment 33528 [details]
test.c

Comment 5 Sundtek 2010-02-24 08:43:55 UTC

Created attachment 33529 [details]
valgrind of the application without resizing it

Comment 6 GitLab Migration User 2019-09-24 17:08:17 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/drm/issues/2.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.