Bug 75732

Summary: [r600g] Memory leak with celestia, RV790
Product: Mesa Reporter: Chris Rankin <rankincj>
Component: Drivers/Gallium/r600Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium    
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Chris Rankin 2014-03-03 23:26:14 UTC 
This bug might be a duplicate of #74549. However, WoW + Wine + Valgrind is currently proving to be an intractable problem, and so I've decided to Valgrind celestia instead (since at least I've managed to get THAT to running again on x86_64!!!!!!!)

For this test, git HEAD was set to:

commit 9bace99d77642f8fbd46b1f0be025ad758f83f5e
Author: Zack Rusin <zackr@vmware.com>
Date:   Tue Jan 28 16:34:18 2014 -0500

    gallivm: fix opcode and function nesting

I executed the following command:

$ valgrind --leak-check=full celestia

and amidst all of the other issues that Valgrind complained about, it also happened to mention this:

==7446== 352 bytes in 1 blocks are possibly lost in loss record 8,803 of 9,718
==7446==    at 0x4C291D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7446==    by 0x4011C44: _dl_allocate_tls (dl-tls.c:296)
==7446==    by 0xBEE8862: pthread_create@@GLIBC_2.2.5 (allocatestack.c:580)
==7446==    by 0x22F18208: pipe_thread_create.constprop.7 (threads_posix.h:264)
==7446==    by 0x22F18B47: radeon_drm_winsys_create (radeon_drm_winsys.c:661)
==7446==    by 0x22BA18F5: create_screen (drm_target.c:38)
==7446==    by 0x22F13876: dri2_init_screen (dri2.c:1044)
==7446==    by 0x22BA295F: driCreateNewScreen2 (dri_util.c:158)
==7446==    by 0x52DC260: dri2CreateScreen (dri2_glx.c:1240)
==7446==    by 0x52B67E8: __glXInitialize (glxext.c:778)
==7446==    by 0x52B31AA: GetGLXPrivScreenConfig.part.2 (glxcmds.c:174)
==7446==    by 0x52B392F: glXChooseVisual (glxcmds.c:170)
==7446==
==7446== 360 bytes in 5 blocks are possibly lost in loss record 8,811 of 9,718
==7446==    at 0x4C291D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7446==    by 0xA24CEC6: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.3800.2)
==7446==    by 0x9FBC1D4: g_closure_new_simple (in /usr/lib64/libgobject-2.0.so.0.3800.2)
==7446==    by 0x9FBD671: g_cclosure_new (in /usr/lib64/libgobject-2.0.so.0.3800.2)
==7446==    by 0x781E83F: gtk_action_group_add_toggle_actions_full (in /usr/lib64/libgtk-x11-2.0.so.0.2400.22)
==7446==    by 0x4623F5: main (in /usr/bin/celestia)
Comment 1 Chris Rankin 2014-03-04 00:43:51 UTC 
Having recompiled the current Mesa from git, it looks as if radeon_winsys_destroy() in src/gallium/winsys/radeon/drm/radeon_drm_winsys.c is not being called on exit.
Comment 2 Michel Dänzer 2014-03-04 04:11:49 UTC 
(In reply to comment #1)
> Having recompiled the current Mesa from git, it looks as if
> radeon_winsys_destroy() in src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> is not being called on exit.

That only explains 352 leaked bytes though, over the whole lifetime of the celestia process.


Please describe the problem in more detail. Why do you think there is a leak?
Comment 3 Chris Rankin 2014-03-04 08:53:23 UTC 
(In reply to comment #2)
> Please describe the problem in more detail. Why do you think there is a leak?

I think there's a leak because "Valgrind says there's a leak" and "Valgrind is a program that finds memory leaks". Simple, really.
Comment 4 Chris Rankin 2014-03-04 08:57:27 UTC 
(In reply to comment #2)
> Please describe the problem in more detail. Why do you think there is a leak?

(There's also an underlying hypothesis that WoW cannot possibly be the only program in existence to be experiencing memory problems under Mesa. However, since valgrinding 32 bit WoW on a 64 bit box is currently beyond me, I am hunting for memory errors in other workloads instead, in the hope that they might provide some insight.)
Comment 5 Michel Dänzer 2014-03-05 02:47:15 UTC 
(In reply to comment #4)
> [...] since valgrinding 32 bit WoW on a 64 bit box is currently beyond me,

As suggested in your WoW bug report, please try valgrind on replaying an apitrace instead.


> I am hunting for memory errors in other workloads instead, in the hope that
> they might provide some insight.)

valgrind finds one 352 byte leak with celestia. That can't possibly explain the issues you're having with WoW.
Comment 6 Chris Rankin 2014-03-05 08:48:42 UTC 
(In reply to comment #5)
> valgrind finds one 352 byte leak with celestia. That can't possibly explain
> the issues you're having with WoW.

I raised this as a separate issue for a reason... ;-). But I doubt that Mesa contains functionality that is *specific* to WoW; other apps *must* be affected by #74549 - although perhaps not as noticeably.
Comment 7 Marek Olšák 2014-03-05 14:31:47 UTC 
Leaking a radeon_winsys allocation is hardly an issue. There is only one instance of the winsys per process anyway. This is really harmless. I wouldn't even bother trying to fix this leak (if there really is a leak).
Comment 8 GitLab Migration User 2019-09-18 19:15:39 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/mesa/issues/499.

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.