Bug 26946

Summary:	[bisected] CRTC cursor BO leak in 2D
Product:	xorg	Reporter:	Shuang He <shuang.he>
Component:	Driver/intel	Assignee:	Chris Wilson <chris>
Status:	CLOSED WONTFIX	QA Contact:	Xorg Project Team <xorg-team>
Severity:	trivial
Priority:	high
Version:	git
Hardware:	Other
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Shuang He 2010-03-07 18:59:16 UTC

System Environment:
--------------------------
Mesa:		(master)ccbe3f0314c8278c55e1046a619969ae539564de
Xserver:		(master)bbae92795c7eab062e6722c42fa7915e0cee5d69
Xf86_video_intel:		(master)8ece6cf5afa1bb0d8d9328696422f42f3c3adbd6
Kernel:       (drm-intel-next)6070a4a928f8c92b9fae7d6717ebbb05f425d6b2


Bug detailed description:
-------------------------
This issue happens on both 945GM and G45.
Just start and close X will trigger this issue.

bisect result shows that this is due to following commit:
commit e37b562083aa3293e0c009171724a3f122d8a32d
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Mar 4 10:23:12 2010 -0800

    Init CRTC cursors with CRTC setup instead of i830_memory.


Here's a output from valgrind:
process 6339 complete
root      6289     1 54 04:01 tty8     00:00:05 valgrind --leak-check=yes /opt/X11R7/bin/X
6289
==6289== 0 bytes in 2 blocks are definitely lost in loss record 2 of 734
FAIL: Found mem leak at:
==6289== 0 bytes in 2 blocks are definitely lost in loss record 2 of 734
==6289==    at 0x77AE8F2: drm_intel_gem_bo_alloc_internal (intel_bufmgr_gem.c:656)
==6289==    by 0x7588038: drmmode_pre_init (drmmode_display.c:627)
==6289==    by 0x7569A74: I830PreInit (i830_driver.c:709)
==6289==    by 0x46E237: InitOutput (xf86Init.c:831)
==6289==    by 0x42162C: main (main.c:205)

Comment 1 Eric Anholt 2010-03-08 16:51:26 UTC

Apparently the destroy function isn't getting called?  Either way, it's leaking allocated-once data when the server's about to go down anyway.

Comment 2 Chris Wilson 2010-05-26 13:37:14 UTC

I am failing to reproduce this on current xserver and ddx. Can you confirm if this has been fixed? The driver code looks correct, as Eric said, so if anything it's a failure to call the destroy routine by the xserver.

Comment 3 Shuang He 2010-05-27 20:24:58 UTC

(In reply to comment #2)
> I am failing to reproduce this on current xserver and ddx. Can you confirm if
> this has been fixed? The driver code looks correct, as Eric said, so if
> anything it's a failure to call the destroy routine by the xserver.

Per my debug, cursor is allocated in drmmode_crtc_init(), that should be freed by the time of calling drmmode_crtc_destroy(), but unfortunately, no one is calling xf86CrtcDestroy(), which will in turn call drmmode_crtc_destroy()

Comment 4 Chris Wilson 2010-07-09 06:14:14 UTC

commit 6ff369cd2602497ee11273b50f76d1a7bf25991d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 9 14:00:31 2010 +0100

    drmmode: Destroy Crtc on screen shutdown
    
    Should fix:
    
      Bug 26946 - CRTC cursor BO leak in 2D
      https://bugs.freedesktop.org/show_bug.cgi?id=26946
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Comment 5 Shuang He 2010-07-12 20:11:01 UTC

It's not totally fixed. 
seems drmmode_pre_init() get called twice because drmmode->mode_res->count_crtcs = 2, but drmmode_close_screen() only get called once.

Comment 6 Chris Wilson 2010-07-13 02:22:56 UTC

Sigh. I wasn't paying attention. This should fix that snafu:

commit 5de1b74d64f807b59c730871d4cb171484db9780
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jul 13 09:34:53 2010 +0100

    modes: There may be more than one crtc and output... DESTROY THEM ALL!
    
    In order to cleanup all CRTCs and outputs on shutdown, we need to keep a
    list of the individual structures and iterate over that list on
    shutdown.
    
    Also, the output and crtcs are configured just once and not for each
    screen generation so move the shutdown to the termination and not on
    CloseScreen. Oops.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Comment 7 Chris Wilson 2010-07-13 03:02:43 UTC

Hmm, staring at the code a bit more, the xserver never tries to free the screen on exit so there is no way we can be valgrind clean. We just have to avoid per-generation leaks.

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.