Re: [Mesa-dev] gallium r300 driver for PowerPC

[Herminio Hernandez Jr.]

Will do and I will run the piglit test suite as well. 

Sent from my iPhone

> On May 1, 2016, at 8:25 PM, Michel Dänzer  wrote:
> 
>> On 26.04.2016 23:32, Herminio Hernandez, Jr. wrote:
>> I have done some more debugging and I do have a question. The clearest,
>> repeatable issue I am seeing is when I run glxgears in apitrace. The
>> crash always occrs at GLXChooseVisual. It returns NULL and from the
>> documentation this means that it is encountering an undefined attribute.
> 
> This happens because the driver doesn't support the format chosen by
> st/dri (the DRI state tracker). Please try Marek's latest patch attached
> to https://bugs.freedesktop.org/show_bug.cgi?id=71789 .
> 
> 
> -- 
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Michel Dänzer]

On 26.04.2016 23:32, Herminio Hernandez, Jr. wrote:
> I have done some more debugging and I do have a question. The clearest,
> repeatable issue I am seeing is when I run glxgears in apitrace. The
> crash always occrs at GLXChooseVisual. It returns NULL and from the
> documentation this means that it is encountering an undefined attribute.

This happens because the driver doesn't support the format chosen by
st/dri (the DRI state tracker). Please try Marek's latest patch attached
to https://bugs.freedesktop.org/show_bug.cgi?id=71789 .


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Herminio Hernandez, Jr.]

I have done some more debugging and I do have a question. The clearest,
repeatable issue I am seeing is when I run glxgears in apitrace. The crash
always occrs at GLXChooseVisual. It returns NULL and from the documentation
this means that it is encountering an undefined attribute. I see this when
I am running either Ubuntu or Debian. The other tools (ie gdb and valgrind)
have not given as clear an indication where the problem is (granted I admit
that I may be not using them correctly either). My question is how would I
determine what is causing this? I have search and have not found a clear
explanation on how to troubleshoot this on the web.

Thanks
Herminio

On Tue, Feb 2, 2016 at 4:08 PM, Herminio Hernandez, Jr. <
herminio.hernande...@gmail.com> wrote:

> Mike,
>
> When I trace in gdb and let the program run I get the standard error:
>
> 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
> libGL error: No matching fbConfigs or visuals found
> libGL error: failed to load driver: r300
> libGL: OpenDriver: trying /usr/lib/powerpc-linux-gnu/dri/tls/swrast_dri.so
> libGL: OpenDriver: trying /usr/lib/powerpc-linux-gnu/dri/swrast_dri.so
> libGL error: No matching fbConfigs or visuals found
> libGL error: failed to load driver: swrast
>
> Both r300 and swrast driver fail to load and I do not get a backtrace.
> When run gdb again and force an interrupt at the point the r300 fails to
> load I see in the trace that it is failing at the driOpenDriver function.
> When I run the program again and stop when the swrast driver fails in the
> trace I see it fail at the same spot. Unless I am reading the backtrace
> wrong I think that is where is the issue is. I am attaching the file so you
> can see.
>
> Herminio
>
>
>
> > On Jan 26, 2016, at 7:49 PM, Michel Dänzer  wrote:
> >
> > On 26.01.2016 19:15, Herminio Hernandez Jr.  wrote:
> >> Would the same thing apply swrast driver? I see glxgears trying to
> >> fall back to it and relieving the same error.
> >
> > Possibly, though that's a bit weird indeed. Anyway, trace the code
> > execution (e.g. in gdb) and see.
> >
> >
> > --
> > Earthling Michel Dänzer   |   http://www.amd.com
> > Libre software enthusiast | Mesa and X developer
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Herminio Hernandez, Jr.]

Mike,

When I trace in gdb and let the program run I get the standard error:

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
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: r300
libGL: OpenDriver: trying /usr/lib/powerpc-linux-gnu/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/powerpc-linux-gnu/dri/swrast_dri.so
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

Both r300 and swrast driver fail to load and I do not get a backtrace. When run 
gdb again and force an interrupt at the point the r300 fails to load I see in 
the trace that it is failing at the driOpenDriver function. When I run the 
program again and stop when the swrast driver fails in the trace I see it fail 
at the same spot. Unless I am reading the backtrace wrong I think that is where 
is the issue is. I am attaching the file so you can see.

Herminio



glxgears-gdb2.log
Description: Binary data

> On Jan 26, 2016, at 7:49 PM, Michel Dänzer  wrote:
> 
> On 26.01.2016 19:15, Herminio Hernandez Jr.  wrote:
>> Would the same thing apply swrast driver? I see glxgears trying to
>> fall back to it and relieving the same error.
> 
> Possibly, though that's a bit weird indeed. Anyway, trace the code
> execution (e.g. in gdb) and see.
> 
> 
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Michel Dänzer]

On 25.01.2016 10: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.

I'm afraid not. The leaks are probably just due to failing to clean up
some things in error paths.

You need to work back from the point where dri2CreateScreen fails.
Assuming it still prints "libGL error: No matching fbConfigs or visuals
found" for you, it can only be one (or both) of the driConvertConfigs
calls failing, probably because the r300 driver says it doesn't support
the Gallium formats which the code in src/gallium/state_trackers/dri/
computes as corresponding to the DRI formats.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Herminio Hernandez Jr.]

Would the same thing apply swrast driver? I see glxgears trying to fall back to 
it and relieving the same error. 

Sent from my iPhone

> On Jan 26, 2016, at 3:31 AM, Michel Dänzer  wrote:
> 
>> On 25.01.2016 10: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.
> 
> I'm afraid not. The leaks are probably just due to failing to clean up
> some things in error paths.
> 
> You need to work back from the point where dri2CreateScreen fails.
> Assuming it still prints "libGL error: No matching fbConfigs or visuals
> found" for you, it can only be one (or both) of the driConvertConfigs
> calls failing, probably because the r300 driver says it doesn't support
> the Gallium formats which the code in src/gallium/state_trackers/dri/
> computes as corresponding to the DRI formats.
> 
> 
> -- 
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Michel Dänzer]

On 26.01.2016 19:15, Herminio Hernandez Jr.  wrote:
> Would the same thing apply swrast driver? I see glxgears trying to
> fall back to it and relieving the same error.

Possibly, though that's a bit weird indeed. Anyway, trace the code
execution (e.g. in gdb) and see.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Nicolai Hähnle]

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 , 
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 , nsid=-2, argc=1, 
argv=0xb424, env=0xb42c) 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 , args=0xbfffeb38) at dl-error.c:187
#6  0x0f3bb7f4 in _dlerror_run (operate=0xf3badc0 , 
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=, 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=0x1ee0, argc=1, argv=0xb424, 
auxvec=0xb4d0, init=,
 rtld_fini=rtld_fini@entry=0xb7fcfad0 <_dl_fini>, stack_end=, 
fini=)
 at ../csu/libc-start.c:291
#18 0x0fa15c14 in __libc_start_main (argc=, argv=, 
ev=, auxvec=,
 rtld_fini=0xb7fcfad0 <_dl_fini>, stinfo=, 
stack_on_entry=)
 at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:94
#19 0x in ?? ()
(gdb) q







On Dec 14, 2015, at 11:13 AM, Nicolai Hähnle  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)

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Herminio Hernandez Jr.]

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  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 
>> , 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 , nsid=-2, argc=1, 
>> argv=0xb424, env=0xb42c) 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 , args=0xbfffeb38) at dl-error.c:187
>> #6  0x0f3bb7f4 in _dlerror_run (operate=0xf3badc0 , 
>> 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=, dpy=0x10025a10)
>> at ../../../../src/glx/glxcmds.c:168
>> #14 glXChooseVisual (dpy=0x10025a10, screen=0, 

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Nicolai Hähnle]

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  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 , 
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 , nsid=-2, argc=1, 
argv=0xb424, env=0xb42c) 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 , args=0xbfffeb38) at dl-error.c:187
#6  0x0f3bb7f4 in _dlerror_run (operate=0xf3badc0 , 
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=, dpy=0x10025a10)
 at ../../../../src/glx/glxcmds.c:168
#14 glXChooseVisual (dpy=0x10025a10, 

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Herminio Hernandez, Jr.]

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
(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 , 
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 , nsid=-2, argc=1, 
argv=0xb424, env=0xb42c) 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 , args=0xbfffeb38) at dl-error.c:187
#6  0x0f3bb7f4 in _dlerror_run (operate=0xf3badc0 , 
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=, 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=0x1ee0, argc=1, argv=0xb424, 
auxvec=0xb4d0, init=,
rtld_fini=rtld_fini@entry=0xb7fcfad0 <_dl_fini>, stack_end=, 
fini=)
at ../csu/libc-start.c:291
#18 0x0fa15c14 in __libc_start_main (argc=, argv=, ev=, auxvec=,
rtld_fini=0xb7fcfad0 <_dl_fini>, stinfo=, 
stack_on_entry=)
at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:94
#19 0x in ?? ()
(gdb) q






> On Dec 14, 2015, at 11:13 AM, Nicolai Hähnle  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)

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Nicolai Hähnle]

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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] gallium r300 driver for PowerPC

[Herminio Hernandez, Jr.]

Hello,

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?

Herminio









 ==20991== LEAK SUMMARY:
==20991==definitely lost: 0 bytes in 0 blocks
==20991==indirectly lost: 0 bytes in 0 blocks
==20991==  possibly lost: 592,952 bytes in 2,927 blocks
==20991==still reachable: 1,359,273 bytes in 1,538 blocks
==20991== suppressed: 0 bytes in 0 blocks
==20991== Reachable blocks (those to which a pointer was found) are not shown.
==20991== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==20991== 
==20991== ERROR SUMMARY: 672 errors from 672 contexts (suppressed: 0 from 0)
==20991== ERROR SUMMARY: 672 errors from 672 contexts (suppressed: 0 from 0)
==21922== HEAP SUMMARY:
==21922== in use at exit: 96,554 bytes in 192 blocks
==21922==   total heap usage: 1,312 allocs, 1,120 frees, 413,711 bytes allocated
==21922== 
==21922== Searching for pointers to 192 not-freed blocks
==21922== Checked 356,496 bytes
==21922== 
==21922== 5 bytes in 1 blocks are definitely lost in loss record 7 of 81
==21922==at 0xFFB2868: malloc (vg_replace_malloc.c:299)
==21922==by 0xFA073FB: strdup (in /lib/powerpc-linux-gnu/libc-2.21.so)
==21922==by 0xED1DA37: ???
==21922==by 0xE93B313: ???
==21922==by 0xEC12C6B: ???
==21922==by 0xEC0EAFB: ???
==21922==by 0xFDFB1D3: dri2CreateScreen (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC61AF: __glXInitialize (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC10A3: GetGLXPrivScreenConfig.part.2 (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC1303: glXChooseVisual (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0x10002A33: ??? (in /usr/bin/glxgears)
==21922==by 0x100010A3: ??? (in /usr/bin/glxgears)
==21922== 
==21922== 108 (12 direct, 96 indirect) bytes in 1 blocks are definitely lost in 
loss record 55 of 81
==21922==at 0xFFB2868: malloc (vg_replace_malloc.c:299)
==21922==by 0xECAD53B: ???
==21922==by 0xEF1F3CB: ???
==21922==by 0xE93B44B: ???
==21922==by 0xEC12C6B: ???
==21922==by 0xEC0EAFB: ???
==21922==by 0xFDFB1D3: dri2CreateScreen (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC61AF: __glXInitialize (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC10A3: GetGLXPrivScreenConfig.part.2 (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC1303: glXChooseVisual (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0x10002A33: ??? (in /usr/bin/glxgears)
==21922==by 0x100010A3: ??? (in /usr/bin/glxgears)
==21922== 
==21922== 3,172 (76 direct, 3,096 indirect) bytes in 1 blocks are definitely 
lost in loss record 75 of 81
==21922==at 0xFFB50A4: calloc (vg_replace_malloc.c:711)
==21922==by 0xEC0DA53: ???
==21922==by 0xEC1168F: ???
==21922==by 0xEC12CFF: ???
==21922==by 0xEC0EAFB: ???
==21922==by 0xFDFB1D3: dri2CreateScreen (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC61AF: __glXInitialize (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC10A3: GetGLXPrivScreenConfig.part.2 (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC1303: glXChooseVisual (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Eero Tamminen]

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