Bug 112196 - Memory leak in Intel driver
Summary: Memory leak in Intel driver
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: not set critical
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
Depends on:
Reported: 2019-11-01 18:34 UTC by jdemello
Modified: 2019-11-27 13:51 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Stack trace of gem_creates that were not also gem_closed (9.93 KB, text/plain)
2019-11-01 18:34 UTC, jdemello
no flags Details
dmesg.log (144.67 KB, text/plain)
2019-11-01 18:36 UTC, jdemello
no flags Details
Xorg.0.log (21.92 KB, text/plain)
2019-11-01 18:36 UTC, jdemello
no flags Details
i915_gem_objects.txt (1.68 KB, text/plain)
2019-11-01 18:55 UTC, jdemello
no flags Details
xrestop.txt (1.66 KB, text/plain)
2019-11-05 16:31 UTC, jdemello
no flags Details

Description jdemello 2019-11-01 18:34:14 UTC
We have a software solution that is based of Ubuntu 16.04 (fully updated).

uname -a: Linux EnGageRP-a371 4.15.0-62-generic #69~16.04.1-Ubuntu SMP Fri Sep 6 02:43:35 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Graphics driver version: 2:2.99.917+git20160325-1ubuntu1

Our software appears to have no free memory after a while. top does not indicated any increase in RSS or Virtual Memory on any process. Kernel buffers/cache seems to grow over time. Swap gets filled up over time and eventually soon after either the player hangs or the OOM kills Xorg and everything recovers.

The workload causing this varies over time and repeats every 15min. It essentially consists of at most two video at a time (no hardware acceleration enabled), along with a browser running something from https://stackla.com/ and images. The video and the browser may run in parallel, but otherwise if alone, it is in full screen. All videos are at most 1080p.

From what I understand, Xorg process seems to be leaking gem objects and that this might actually be indicative of a bug in the Intel driver.

I have tried tracing calls to gem_create and gem_close in Xorg, and a few outstanding allocations. Please see attached summary.txt.
Comment 1 jdemello 2019-11-01 18:34:43 UTC
Created attachment 145871 [details]
Stack trace of gem_creates that were not also gem_closed
Comment 2 jdemello 2019-11-01 18:36:01 UTC
Created attachment 145872 [details]
Comment 3 jdemello 2019-11-01 18:36:20 UTC
Created attachment 145873 [details]
Comment 4 Chris Wilson 2019-11-01 18:44:09 UTC
That would be extremely surprising. You can enable valgrind if you want to track allocations; but first check xrestop and look at what clients still have pixmap references.
Comment 5 jdemello 2019-11-01 18:55:46 UTC
Created attachment 145874 [details]

The output of /sys/kernel/debug/dri/0/i915_gem_object
Comment 6 jdemello 2019-11-01 18:56:29 UTC
@chris I'll try collecting that information. I'll need some time.
Comment 7 jdemello 2019-11-05 16:31:52 UTC
Created attachment 145891 [details]

Attached output of xrestop.txt when gem_object count was:

 Xorg: 246 objects, 7526064128 bytes (0 active, 546791424 inactive, 200171520 global, 7520288768 shared, 7006183424 unbound)
Comment 8 Martin Peres 2019-11-27 13:51:30 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/xorg/driver/xf86-video-intel/issues/170.

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.