[Mesa-dev] gallium r300 driver for PowerPC

Nicolai Hähnle nhaehnle at gmail.com
Mon Jan 25 08:32:46 PST 2016 

On 25.01.2016 10:58, Herminio Hernandez Jr.  wrote:
> Someone suggested that I should kill the program at runtime to see what the issue was. I did the same thing with valgrind and saw some similar out puts. See below
>
> It is just a sample I can send more output. I wanted to compare the result I got from gdb with what I was seeing with Valgrind. Apologies if I was not clear.
>
> Just to be clear this my first real attempt to debug and troubleshoot a program. So I am completely open to criticism if I am doing something wrong.
>
> ==30671== 668 bytes in 1 blocks are still reachable in loss record 60 of 70                              ==30671==    at 0xFFB50A4: calloc (vg_replace_malloc.c:711)           ==30671==    by 0x400C537: _dl_new_object (in /lib/powerpc-linux-gnu/ld-2.21.so)                         ==30671==    by 0x4007847: _dl_map_object_from_fd (in /lib/powerpc-linux-gnu/ld-2.21.so)                 ==30671==    by 0x4009DCB: _dl_map_object (in /lib/powerpc-linux-gnu/ld-2.21.so)                         ==30671==    by 0x4015673: dl_open_worker (in /lib/powerpc-linux-gnu/ld-2.21.so)
> ==30671==    by 0x401031B: _dl_catch_error (in /lib/powerpc-linux-gnu/ld-2.21.so)
> ==30671==    by 0x4014EBF: _dl_open (in /lib/powerpc-linux-gnu/ld-2.21.so)
>   ==30671==    by 0xF306E43: dlopen_doit (in /lib/powerpc-linux-gnu/libdl-2.21.so)
>   ==30671==    by 0x401031B: _dl_catch_error (in /lib/powerpc-linux-gnu/ld-2.21.so)
> ==30671==    by 0xF3077F3: _dlerror_run (in /lib/powerpc-linux-gnu/libdl-2.21.so)
> ==30671==    by 0xF306F1F: dlopen@@GLIBC_2.1 (in /lib/powerpc-linux-gnu/libdl-2.21.so)
> ==30671==    by 0xFDE984B: driOpenDriver (dri_common.c:141)           ==30671==

This means that some memory that was allocated during the program run 
was not freed before program end. However, the block is still reachable, 
which usually indicates something that is not a genuine problem.

It seems everything is working fine, so I still don't understand what 
you're worried about.

Nicolai

> Sent from my iPhone
>
>> On Jan 25, 2016, at 9:41 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>>
>>> On 24.01.2016 20:56, Herminio Hernandez, Jr. wrote:
>>> So I believe I have all the debugging symbols installed. From what I am seeing in gdb and valgrind I am still thinking the issue is in the glx branch. For gdb I ran it twice and stopped it during it attempt to load the r300 driver and in it attempt to load the swrast driver. Both failed at the same place in the trace see below. Some is breaking when dlopen tries to load the driver. Just want to verify that I am looking at the right thing. Thanks!
>>>
>>> Herminio
>>>
>>> Starting program: /usr/bin/glxgears
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
>>> libGL: OpenDriver: trying /usr/lib/powerpc-linux-gnu/dri/tls/r300_dri.so
>>> libGL: OpenDriver: trying /usr/lib/powerpc-linux-gnu/dri/r300_dri.so
>>> ^C^CQuit
>>
>> So you do have the debugging symbols now, but this looks like you just interrupted the program manually. What's the point of that?
>>
>> You originally reported some Valgrind issues. Do those still exist? What is really the problem?
>>
>> Cheers,
>> Nicolai
>>
>>> (gdb) bt
>>> #0  __GI__dl_debug_state () at dl-debug.c:74
>>> #1  0xb7fd4730 in dl_open_worker (a=a at entry=0xbfffe7d8) at dl-open.c:306
>>> #2  0xb7fcf31c in _dl_catch_error (objname=objname at entry=0xbfffe800, errstring=errstring at entry=0xbfffe7fc,
>>>      mallocedp=mallocedp at entry=0xbfffe804, operate=0xb7fd4560 <dl_open_worker>, args=args at entry=0xbfffe7d8) at dl-error.c:187
>>> #3  0xb7fd3ec0 in _dl_open (file=0xbfffeb64 "/usr/lib/powerpc-linux-gnu/dri/r300_dri.so", mode=-2147483390,
>>>      caller_dlopen=0xfe728c8 <driOpenDriver+472>, nsid=-2, argc=1, argv=0xbffff424, env=0xbffff42c) at dl-open.c:653
>>> #4  0x0f3bae44 in dlopen_doit (a=a at entry=0xbfffeb38) at dlopen.c:66
>>> #5  0xb7fcf31c in _dl_catch_error (objname=0x10031c84, errstring=0x10031c88, mallocedp=0x10031c80,
>>>      operate=0xf3badc0 <dlopen_doit>, args=0xbfffeb38) at dl-error.c:187
>>> #6  0x0f3bb7f4 in _dlerror_run (operate=0xf3badc0 <dlopen_doit>, args=args at entry=0xbfffeb38) at dlerror.c:163
>>> #7  0x0f3baf20 in __dlopen (file=file at entry=0xbfffeb64 "/usr/lib/powerpc-linux-gnu/dri/r300_dri.so", mode=mode at entry=258)
>>>      at dlopen.c:87
>>> #8  0x0fe728c8 in driOpenDriver (driverName=0x10031c68 "r300") at ../../../../src/glx/dri_common.c:141
>>> #9  0x0fe76980 in dri2CreateScreen (screen=0, priv=0x1002fc20) at ../../../../src/glx/dri2_glx.c:1211
>>> #10 0x0fe41bb0 in AllocAndFetchScreenConfigs (priv=0x1002fc20, dpy=0x10025a10) at ../../../../src/glx/glxext.c:799
>>> #11 __glXInitialize (dpy=dpy at entry=0x10025a10) at ../../../../src/glx/glxext.c:910
>>> #12 0x0fe3caa4 in GetGLXPrivScreenConfig (dpy=dpy at entry=0x10025a10, scrn=scrn at entry=0, ppriv=ppriv at entry=0xbfffed50,
>>>      ppsc=ppsc at entry=0xbfffed54) at ../../../../src/glx/glxcmds.c:172
>>> #13 0x0fe3cd04 in GetGLXPrivScreenConfig (ppsc=0xbfffed54, ppriv=0xbfffed50, scrn=<optimized out>, dpy=0x10025a10)
>>>      at ../../../../src/glx/glxcmds.c:168
>>> #14 glXChooseVisual (dpy=0x10025a10, screen=0, attribList=0xbfffef3c) at ../../../../src/glx/glxcmds.c:1249
>>> #15 0x10002a34 in ?? ()
>>> #16 0x100010a4 in ?? ()
>>> #17 0x0fa15a14 in generic_start_main (main=0x10000ee0, argc=1, argv=0xbffff424, auxvec=0xbffff4d0, init=<optimized out>,
>>>      rtld_fini=rtld_fini at entry=0xb7fcfad0 <_dl_fini>, stack_end=<optimized out>, fini=<optimized out>)
>>>      at ../csu/libc-start.c:291
>>> #18 0x0fa15c14 in __libc_start_main (argc=<optimized out>, argv=<optimized out>, ev=<optimized out>, auxvec=<optimized out>,
>>>      rtld_fini=0xb7fcfad0 <_dl_fini>, stinfo=<optimized out>, stack_on_entry=<optimized out>)
>>>      at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:94
>>> #19 0x00000000 in ?? ()
>>> (gdb) q
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Dec 14, 2015, at 11:13 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>>>>
>>>> On 14.12.2015 04:10, Eero Tamminen wrote:
>>>>>> 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.
>>>>
>>>> This is below dri2CreateScreen in the call stack, so it's actually quite plausible that it's in the driver. Make sure you have those debug symbols.
>>>>
>>>> Cheers,
>>>> Nicolai
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>

More information about the mesa-dev mailing list