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)
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.
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.
(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()
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>
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.
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>
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.