tuxkart-devel

Re: [TuxKart-devel] tuxkart cvs being slow...

[<ri...@ae...>]

 That would explain why after a while it gets so, so, so damn slow=20
that I have =20
no choice, but to reboot the system.=20
=20
 There's a KDE utility called Valgrind that can detect memory=20
allocation bugs. =20
I dunno how it works, but it might be a good idea for a programmer=20
to use it.=20
 Valgrind's webpage: http://valgrind.kde.org/=20
=20
Cheers,=20
 Ricardo=20
=20
Em Sexta, 3 de Setembro de 2004 10:45, o Steve Baker escreveu:=20
> Pascal Giard wrote:=20
> > after playing for ~25secs:=20
> >=20
> > Active:         227192 kB=20
> > Inactive:           52 kB=20
> >=20
> > More infos: I played a quick race in "race track" using penny in=20
320x240=20
> > window mode. It started lagging very fast, after ~16secs.=20
>=20
> No wonder it's going slow after a while - it's swapping!=20
>=20
-- =20
There's small choice in rotten apples.=20
                -- William Shakespeare, "The Taming of the Shrew"=20
_________________________________________________________
Revista S=E1bado - 12 edi=E7=F5es por um euro - Sem Compromisso=20
clique aqui: http://revistasabado.online.pt

Re: [TuxKart-devel] tuxkart cvs being slow...

[Christoph B. <chr...@gm...>]

I worked several times with valgrind. And I storngly recommend to use=20
version 2.1 and above. 2.2 should work on ppc architecture, but that's=20
experimental. 2.0 is SLOW! And I mean it!
Working with valgrind is really easy, simply run:

valgrind --tool=3Dmemcheck --leak-check=3Dyes ./tuxkart

and look at the output (if it's much output, you can tell valgrind to=20
use a logfile, but I don't know the option right now)

ri...@ae... wrote:

> That would explain why after a while it gets so, so, so damn slow=20
>that I have =20
>no choice, but to reboot the system.=20
>=20
> There's a KDE utility called Valgrind that can detect memory=20
>allocation bugs. =20
>I dunno how it works, but it might be a good idea for a programmer=20
>to use it.=20
> Valgrind's webpage: http://valgrind.kde.org/=20
>=20
>Cheers,=20
> Ricardo=20
>=20
>Em Sexta, 3 de Setembro de 2004 10:45, o Steve Baker escreveu:=20
> =20
>
>>Pascal Giard wrote:=20
>>   =20
>>
>>>after playing for ~25secs:=20
>>>
>>>Active:         227192 kB=20
>>>Inactive:           52 kB=20
>>>
>>>More infos: I played a quick race in "race track" using penny in=20
>>>     =20
>>>
>320x240=20
> =20
>
>>>window mode. It started lagging very fast, after ~16secs.=20
>>>     =20
>>>
>>No wonder it's going slow after a while - it's swapping!=20
>>
>>   =20
>>
>-- =20
>There's small choice in rotten apples.=20
>                -- William Shakespeare, "The Taming of the Shrew"=20
>_________________________________________________________
>Revista S=E1bado - 12 edi=E7=F5es por um euro - Sem Compromisso=20
>clique aqui: http://revistasabado.online.pt
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dclick
>_______________________________________________
>Tuxkart-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxkart-devel
>
> =20
>

Re: [TuxKart-devel] tuxkart cvs being slow...

[James G. <j....@vi...>]

On Fri, 2004-09-03 at 13:45, Christoph Brill wrote:
> I worked several times with valgrind. And I storngly recommend to use 
> version 2.1 and above. 2.2 should work on ppc architecture, but that's 
> experimental. 2.0 is SLOW! And I mean it!
> Working with valgrind is really easy, simply run:
> 
> valgrind --tool=memcheck --leak-check=yes ./tuxkart
> 
> and look at the output (if it's much output, you can tell valgrind to 
> use a logfile, but I don't know the option right now)

Putting 2> valgrind.log on the end of the above works.

However, I think valgrind is best left to people with a faster PC than
mine (800MHz).

	James

[TuxKart-devel] Valgrind: hunting possible leaks

[Pascal G. <pa...@gu...>]

With valgrind 2.2, i used the following:

valgrind --tool=memcheck --leak-check=yes ./tuxkart 2> /tmp/leaks.log

the first thing i notice is that the following apears very frequently (27
times just by making my way thru until i reach the track selection screen)
along the way:

==1520== Syscall param ioctl(generic) contains uninitialised or unaddressable
byte(s)
==1520==    at 0x4334AA54: ioctl (in /lib/tls/libc-2.3.2.so)
==1520==    by 0x4497DA91: (within /usr/lib/tls/libGL.so.1.0.5336)
==1520==  Address 0x52BFE3B0 is on thread 1's stack


Some other interesting parts:
-----------------------------

==1520== Use of uninitialised value of size 2
==1520==    at 0x4EED76EA: slSample::changeRate(int) (in
/usr/lib/libplibsl.so.1.8.3)
==1520==    by 0x4EED7366: slSample::autoMatch(slDSP const*) (in
/usr/lib/libplibsl.so.1.8.3)
==1520==    by 0x8070AD9: SoundSystem::SoundSystem() (sl.h:240)
==1520==    by 0x8070F71: initTuxKart(int, int, int) (start_tuxkart.cxx:87)

==1520== Conditional jump or move depends on uninitialised value(s)
==1520==    at 0x1B904A38: strcmp (mac_replace_strmem.c:251)
==1520==    by 0x80702D1: SoundSystem::change_track(char const*) (sound.cxx:57)
==1520==    by 0x8070B18: SoundSystem::SoundSystem() (sound.cxx:113)
==1520==    by 0x8070F71: initTuxKart(int, int, int) (start_tuxkart.cxx:87)


Another one that appears frequently:
------------------------------------

==1520== Use of uninitialised value of size 4
==1520==    at 0x4EEF6E0F: sgBox::extend(float const*) (in
/usr/lib/libplibsg.so.1.8.3)
==1520==    by 0x4F021436: ssgVtxTable::recalcBSphere() (in
/usr/lib/libplibssg.so.1.8.3)
==1520==    by 0x4F02030C: ssgVtxTable::ssgVtxTable(unsigned, ssgVertexArray*,
ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*) (in
/usr/lib/libplibssg.so.1.8.3)
==1520==    by 0x80798F5: ParticleSystem::ParticleSystem(int, int, float, int,
float, float) (ssg.h:159)

I'll stop here for now...

To say the least, i don't really understand how i should react to those
informations... 
Almost all entries mention my /usr/lib/tls/libGL.so.1.0.5336, but if it gets
called the wrong way, it's just plain normal.

I'll try kcachegrind to see if i can get to understand more.

-Pascal
--
Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker)
Projet [e]MoviX[2] (http://movix.sf.net) 
Debian Project (http://www.debian.org)
TuxKart (Wiki (GOTM): http://netpanzer.berlios.de/tuxkart/index.php)

[TuxKart-devel] Valgrind: more informations

[Pascal G. <pa...@gu...>]

I reran valgrind, but i "played" ~20secs.

Attached to this mail, you'll find the comnplete log.

Here's the summary:
==3134== LEAK SUMMARY:
==3134==    definitely lost: 186887 bytes in 621 blocks.
==3134==    possibly lost:   15640 bytes in 9 blocks.
==3134==    still reachable: 4863302 bytes in 86441 blocks.
==3134==         suppressed: 200 bytes in 1 blocks.
==3134== Reachable blocks (those to which a pointer was found) are not shown.
==3134== To see them, rerun with: --show-reachable=yes

Based on that (i don't know how reliable it is) either there isn't much memory
leaks (a sum of 185kb in 621 blocks isn't much) or "definitely lost: 186887
bytes in 621 blocks" means that 186887 bytes is lost 621 times, meaning ~111
Mb and we've an explanation.

Most leaks are in either /usr/lib/libplibssg.so.1.8.3 or KartDriver.cxx.

I hope this helps (and that someone will be able to interpret that information),

-Pascal
--
Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker)
Projet [e]MoviX[2] (http://movix.sf.net) 
Debian Project (http://www.debian.org)
TuxKart (Wiki (GOTM): http://netpanzer.berlios.de/tuxkart/index.php)

Re: [TuxKart-devel] Valgrind: hunting possible leaks

[Matze B. <ma...@br...>]

valgrind has problems with some hacks the nvidia and ati opengl drivers 
are doing.
An "export __GL_FORCE_GENERIC_CPU=1" helps for nvidia cards, for ati you 
can only try to link tuxkart with mesa instead of ati opengl.

On Fri, 3 Sep 2004, Pascal Giard wrote:

> With valgrind 2.2, i used the following:
> 
> valgrind --tool=memcheck --leak-check=yes ./tuxkart 2> /tmp/leaks.log
> 
> the first thing i notice is that the following apears very frequently (27
> times just by making my way thru until i reach the track selection screen)
> along the way:
> 
> ==1520== Syscall param ioctl(generic) contains uninitialised or unaddressable
> byte(s)
> ==1520==    at 0x4334AA54: ioctl (in /lib/tls/libc-2.3.2.so)
> ==1520==    by 0x4497DA91: (within /usr/lib/tls/libGL.so.1.0.5336)
> ==1520==  Address 0x52BFE3B0 is on thread 1's stack
> 
> 
> Some other interesting parts:
> -----------------------------
> 
> ==1520== Use of uninitialised value of size 2
> ==1520==    at 0x4EED76EA: slSample::changeRate(int) (in
> /usr/lib/libplibsl.so.1.8.3)
> ==1520==    by 0x4EED7366: slSample::autoMatch(slDSP const*) (in
> /usr/lib/libplibsl.so.1.8.3)
> ==1520==    by 0x8070AD9: SoundSystem::SoundSystem() (sl.h:240)
> ==1520==    by 0x8070F71: initTuxKart(int, int, int) (start_tuxkart.cxx:87)
> 
> ==1520== Conditional jump or move depends on uninitialised value(s)
> ==1520==    at 0x1B904A38: strcmp (mac_replace_strmem.c:251)
> ==1520==    by 0x80702D1: SoundSystem::change_track(char const*) (sound.cxx:57)
> ==1520==    by 0x8070B18: SoundSystem::SoundSystem() (sound.cxx:113)
> ==1520==    by 0x8070F71: initTuxKart(int, int, int) (start_tuxkart.cxx:87)
These are bugs in plib where uninitialized variables are accessed, I've 
seen them too but didn't find the time yet to investigate as they don't 
seem to harm in most cases...

> 
> 
> Another one that appears frequently:
> ------------------------------------
> 
> ==1520== Use of uninitialised value of size 4
> ==1520==    at 0x4EEF6E0F: sgBox::extend(float const*) (in
> /usr/lib/libplibsg.so.1.8.3)
> ==1520==    by 0x4F021436: ssgVtxTable::recalcBSphere() (in
> /usr/lib/libplibssg.so.1.8.3)
> ==1520==    by 0x4F02030C: ssgVtxTable::ssgVtxTable(unsigned, ssgVertexArray*,
> ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*) (in
> /usr/lib/libplibssg.so.1.8.3)
> ==1520==    by 0x80798F5: ParticleSystem::ParticleSystem(int, int, float, int,
> float, float) (ssg.h:159)
> 
> I'll stop here for now...
> 
> To say the least, i don't really understand how i should react to those
> informations... 
> Almost all entries mention my /usr/lib/tls/libGL.so.1.0.5336, but if it gets
> called the wrong way, it's just plain normal.
> 
> I'll try kcachegrind to see if i can get to understand more.
cachegrind is for testing the performance of an App when you consider cpu 
caches so that you can optimize your code to better fit inside the data 
and command-caches of the cpu. That's only usefull if you need to tweak 
the last 5% performance of your app, we're not at that point in tuxkart 
yet.

Greetings,
	Matze

Re: [TuxKart-devel] Valgrind: hunting possible leaks

[Pascal G. <pa...@gu...>]

On Sat, 4 Sep 2004 14:45:17 +0200 (CEST), Matze Braun wrote
> valgrind has problems with some hacks the nvidia and ati opengl 
> drivers are doing. An "export __GL_FORCE_GENERIC_CPU=1" helps for 
> nvidia cards, for ati you can only try to link tuxkart with mesa 
> instead of ati opengl.

I've an nVidia, i've just tried __GL_FORCE_GENERIC_CPU=1, but i don't see any
difference. They're still alot of false positives in
/usr/lib/tls/libGL.so.1.0.5336.


> > I'll try kcachegrind to see if i can get to understand more.
> cachegrind is for testing the performance of an App when you 
> consider cpu caches so that you can optimize your code to better fit 
> inside the data and command-caches of the cpu. That's only usefull 
> if you need to tweak the last 5% performance of your app, we're not 
> at that point in tuxkart yet.

thanks for the information.

btw, do you see anything usefull in the log i attached to my other email ?

-Pascal
--
Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker)
Projet [e]MoviX[2] (http://movix.sf.net) 
Debian Project (http://www.debian.org)
TuxKart (Wiki (GOTM): http://netpanzer.berlios.de/tuxkart/index.php)

Re: [TuxKart-devel] Valgrind: hunting possible leaks

[Matze B. <ma...@br...>]

On Sat, 4 Sep 2004, Pascal Giard wrote:

> On Sat, 4 Sep 2004 14:45:17 +0200 (CEST), Matze Braun wrote
> > valgrind has problems with some hacks the nvidia and ati opengl 
> > drivers are doing. An "export __GL_FORCE_GENERIC_CPU=1" helps for 
> > nvidia cards, for ati you can only try to link tuxkart with mesa 
> > instead of ati opengl.
> 
> I've an nVidia, i've just tried __GL_FORCE_GENERIC_CPU=1, but i don't see any
> difference. They're still alot of false positives in
> /usr/lib/tls/libGL.so.1.0.5336.
> 
> 
> > > I'll try kcachegrind to see if i can get to understand more.
> > cachegrind is for testing the performance of an App when you 
> > consider cpu caches so that you can optimize your code to better fit 
> > inside the data and command-caches of the cpu. That's only usefull 
> > if you need to tweak the last 5% performance of your app, we're not 
> > at that point in tuxkart yet.
> 
> thanks for the information.
> 
> btw, do you see anything usefull in the log i attached to my other email ?
Well I found lots of unreleased stuff in the tuxkart code and I'm cleaning 
this up at the moment, but might need 1 or 2 days more.

Greetings,
	Matze