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