Bug 112196

Summary: Memory leak in Intel driver
Product: xorg Reporter: jdemello
Component: Driver/intelAssignee: Chris Wilson <chris>
Status: RESOLVED MOVED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: critical    
Priority: not set CC: jdemello
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Stack trace of gem_creates that were not also gem_closed
none
dmesg.log
none
Xorg.0.log
none
i915_gem_objects.txt
none
xrestop.txt none

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]
dmesg.log
Comment 3 jdemello 2019-11-01 18:36:20 UTC 
Created attachment 145873 [details]
Xorg.0.log
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]
i915_gem_objects.txt

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]
xrestop.txt

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.