Hi,
On 12/14/2015 10:44 AM, Herminio Hernandez, Jr. wrote:
I am new to this list. I have been trying to see if I can fix or at least pin
point an issue with Radeon r300 driver failing on PowerPC systems. This has
been a problem for a while and I would like to help to get this fixed. I have
done some debugging with valgrind and I think I may see where the issue is but
I would to have someone double check what I am doing. So when I set my Default
Depth to 16 I do get 3D acceleration but when I set to the default of 24 it
breaks. Valgrind reports memory leaks when I run glxgears with a Default Depth
of 24 but shows no definite memory leaks with a Depth of 16. I then got the
source code and created a dev environment andnran glxgears through valgrind
with my default depth of 24 and saw similar memory leaks. Here is a sample of
what I am seeing.
==25273== 108 (12 direct, 96 indirect) bytes in 1 blocks are definitely lost in
loss record 54 of 78
==25273== at 0xFFB2868: malloc (vg_replace_malloc.c:299)
==25273== by 0xED0457B: ???
==25273== by 0xEEC6F3B: ???
==25273== by 0xE95A78B: ???
==25273== by 0xED7DF7F: ???
==25273== by 0xED7D5DB: ???
==25273== by 0xEC5B377: ???
==25273== by 0xEC567EB: ???
==25273== by 0xFDEDFD3: dri2CreateScreen (dri2_glx.c:1235)
==25273== by 0xFDB866F: AllocAndFetchScreenConfigs (glxext.c:799)
==25273== by 0xFDB866F: __glXInitialize (glxext.c:910)
==25273== by 0xFDB36F3: GetGLXPrivScreenConfig.part.2 (glxcmds.c:172)
==25273== by 0xFDB396B: GetGLXPrivScreenConfig (glxcmds.c:168)
==25273== by 0xFDB396B: glXChooseVisual (glxcmds.c:1249)
It looks like the files in the src/glx branch is where the issue is. I am
attaching the summary portion of the output I got from valgrind. Am I heading
in the right direction?
Install debug symbols for the libraries that Valgrind is complaining
about, to see what actually leaks. Because they all come from through
GetGLXPrivScreenConfig(), I think this is something (inconsequential) in
your X libraries, not Mesa.
If you want to track run time memory leaks, quit the program with a
signal that the application doesn't catch, but which Valgrind can catch
(e.g. SIGHUP could be such). That way you avoid seeing memory leaks
that happen only when the application quits normally (those are also
good to fix, but not relevant for run-time memory usage).
- Eero
PS. Do have you libdrm version that is compiled with Valgrind support?
(If not, Valgrind gives bogus errors because it doesn't know where gfx
memory comes from & what memory areas are valid to access.)
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
