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==
Sent from my iPhone
> On Jan 25, 2016, at 9:41 AM, Nicolai Hähnle <[email protected]> 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@entry=0xbfffe7d8) at dl-open.c:306
>> #2 0xb7fcf31c in _dl_catch_error (objname=objname@entry=0xbfffe800,
>> errstring=errstring@entry=0xbfffe7fc,
>> mallocedp=mallocedp@entry=0xbfffe804, operate=0xb7fd4560
>> <dl_open_worker>, args=args@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@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@entry=0xbfffeb38) at dlerror.c:163
>> #7 0x0f3baf20 in __dlopen (file=file@entry=0xbfffeb64
>> "/usr/lib/powerpc-linux-gnu/dri/r300_dri.so", mode=mode@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@entry=0x10025a10) at
>> ../../../../src/glx/glxext.c:910
>> #12 0x0fe3caa4 in GetGLXPrivScreenConfig (dpy=dpy@entry=0x10025a10,
>> scrn=scrn@entry=0, ppriv=ppriv@entry=0xbfffed50,
>> ppsc=ppsc@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@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 <[email protected]> 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
>>> [email protected]
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
