Valgrind testing

SDL Development
1

(As I’ve been saying on other mailing lists…) If you haven’t tried
Valgrind yet, do it NOW. This thing rocks.

I’ve been running the SDL test apps through Valgrind. Most are REALLY
clean, with zero memory leaks, not just from SDL, but from the entire
program. Nice work, whoever wrote these. :slight_smile:

Here are the problem points. I just ran these through Valgrind; I haven’t
search further.

Memory leak in testpalette (may be a problem in SDL, may be that be never
call SDL_FreeSurface() in the app):

==19779== 180 bytes in 3 blocks are definitely lost in loss record 6 of 10
==19779== at 0x4004314B: malloc (vg_clientfuncs.c:100)
==19779== by 0x40289EB4: SDL_CreateRGBSurface (SDL_surface.c:80)
==19779== by 0x40286D98: SDL_LoadBMP_RW (SDL_bmp.c:214)
==19779== by 0x8048FD0: main (testpalette.c:171)

I get this a lot (may be nothing bad, but probably just an incorrect but
harmless behaviour on our part):

==19797== Conditional jump or move depends on uninitialised value(s)
==19797== at 0x4026EA79: X11_SetKeyboardState (SDL_x11events.c:878)
==19797== by 0x4026DAAD: X11_DispatchEvent (SDL_x11events.c:244)
==19797== by 0x4026E059: X11_PumpEvents (SDL_x11events.c:469)
==19797== by 0x402808FB: SDL_PumpEvents (SDL_events.c:355)

This was in threadwin. Are the TranslateKey leaks out of our control?

==19842== 13 bytes in 1 blocks are definitely lost in loss record 13 of 50
==19842== at 0x4004314B: malloc (vg_clientfuncs.c:100)
==19842== by 0x40453A9D: resolve_name (in /usr/X11R6/lib/libX11.so.6.2)
==19842== by 0x404544FD: _XlcLocaleDirName (in /usr/X11R6/lib/libX11.so.6.2)
==19842== by 0x4044D97A: _XlcDynamicLoad (in /usr/X11R6/lib/libX11.so.6.2)
==19842== by 0x40430CEC: _XOpenLC (in /usr/X11R6/lib/libX11.so.6.2)
==19842== by 0x40430DF5: _XlcCurrentLC (in /usr/X11R6/lib/libX11.so.6.2)
==19842== by 0x4043B28D: _XkbGetCharset (in /usr/X11R6/lib/libX11.so.6.2)
==19842== by 0x40439A95: XkbTranslateKeySym (in /usr/X11R6/lib/libX11.so.6.2)
==19842== by 0x40439CF5: XLookupString (in /usr/X11R6/lib/libX11.so.6.2)
==19842== by 0x4026E621: X11_TranslateKey (SDL_x11events.c:709)

Also in threadwin. Maybe there is a leak in SDL_CreateRGBSurface().

==19842== 60 bytes in 1 blocks are definitely lost in loss record 27 of 50
==19842== at 0x4004314B: malloc (vg_clientfuncs.c:100)
==19842== by 0x40262EB4: SDL_CreateRGBSurface (SDL_surface.c:80)
==19842== by 0x4025FD98: SDL_LoadBMP_RW (SDL_bmp.c:214)
==19842== by 0x8048C81: LoadIconSurface (threadwin.c:27)
==19842== by 0x80491F1: main (threadwin.c:245)
==19842== by 0x402E3577: (within /lib/libc-2.1.3.so)
==19842== by 0x8048BA1: SDL_SetVideoMode (in /home/icculus/projects/SDL12/test/threadwin)

This is from SDL_sound’s playsound app, but I’m posting it because it
looks like an issue in SDL_OpenAudio()…but take the ioctl warning with a
grain of salt; Valgrind might just not know how to treat a /dev/dsp ioctl,
and assumes we’re misbehaving with memory:

==19850== Warning: noted but unhandled ioctl 0x5000 with no size/direction hints
==19850== This could cause spurious value errors to appear.
==19850== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==19850==
==19850== Conditional jump or move depends on uninitialised value(s)
==19850== at 0x40330BDE: SDL_OpenAudio (SDL_audio.c:448)
==19850== by 0x804AFC4: main (playsound.c:995)
==19850== by 0x40683577: (within /lib/libc-2.1.3.so)
==19850== by 0x80493C1: (within /usr/local/bin/playsound)
==19850==
==19850== Use of uninitialised value of size 4
==19850== at 0x40330BDE: SDL_OpenAudio (SDL_audio.c:448)
==19850== by 0x804AFC4: main (playsound.c:995)
==19850== by 0x40683577: (within /lib/libc-2.1.3.so)
==19850== by 0x80493C1: (within /usr/local/bin/playsound)

Xlib is a NASTY memory offender, for the record. :slight_smile:

Who’s bored and wants to do some clean up?

–ryan.

2

In reference to my Valgrind testing the other night: this one was my bug.
Disregard.

This is from SDL_sound’s playsound app, but I’m posting it because it
looks like an issue in SDL_OpenAudio()…but take the ioctl warning with a
grain of salt; Valgrind might just not know how to treat a /dev/dsp ioctl,
and assumes we’re misbehaving with memory:

==19850== Warning: noted but unhandled ioctl 0x5000 with no size/direction hints
==19850== This could cause spurious value errors to appear.
==19850== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==19850==
==19850== Conditional jump or move depends on uninitialised value(s)
==19850== at 0x40330BDE: SDL_OpenAudio (SDL_audio.c:448)
==19850== by 0x804AFC4: main (playsound.c:995)
==19850== by 0x40683577: (within /lib/libc-2.1.3.so)
==19850== by 0x80493C1: (within /usr/local/bin/playsound)
==19850==
==19850== Use of uninitialised value of size 4
==19850== at 0x40330BDE: SDL_OpenAudio (SDL_audio.c:448)
==19850== by 0x804AFC4: main (playsound.c:995)
==19850== by 0x40683577: (within /lib/libc-2.1.3.so)
==19850== by 0x80493C1: (within /usr/local/bin/playsound)

–ryan.

3

Yes - I’ve found this tool to be very helpful - doesn’t work well in real
time, though, and doesn’t support MMX.

Here are some diffs for X11 and yuv. Note that the last part 2nd diff
should probably be a new call to XvQueryAdaptorFree with ainfo and the number of
adaptors, instead of the loop through like I did.

Index: src/video/XFree86/Xv/Xv.c===================================================================
RCS file: /vws/pan/mpeg4ip/lib/SDL/src/video/XFree86/Xv/Xv.c,v
retrieving revision 1.1
diff -c -w -r1.1 Xv.c
*** src/video/XFree86/Xv/Xv.c 2002/04/22 21:38:03 1.1
— src/video/XFree86/Xv/Xv.c 2002/07/29 19:50:18

*** 269,274 ****
— 269,275 ----

 UnlockDisplay(dpy);
 SyncHandle();

  • Xfree(buffer);

    return (Success);
    }
    Index: src/video/x11/SDL_x11yuv.c
    ===================================================================
    RCS file: /vws/pan/mpeg4ip/lib/SDL/src/video/x11/SDL_x11yuv.c,v
    retrieving revision 1.4
    diff -c -w -r1.4 SDL_x11yuv.c
    *** src/video/x11/SDL_x11yuv.c 2002/04/22 21:38:06 1.4
    — src/video/x11/SDL_x11yuv.c 2002/07/29 19:50:18

*** 36,42 ****
#include <sys/shm.h>
#include <X11/extensions/XShm.h>
#include <XFree86/extensions/Xvlib.h>
!
#include “SDL_error.h”
#include “SDL_video.h”
#include “SDL_x11yuv_c.h”
— 36,42 ----
#include <sys/shm.h>
#include <X11/extensions/XShm.h>
#include <XFree86/extensions/Xvlib.h>
! #include <X11/Xlibint.h>
#include “SDL_error.h”
#include “SDL_video.h”
#include “SDL_x11yuv_c.h”

*** 123,131 ****
— 123,138 ----

		}
	 
	}
	 
}

  •   Xfree(formats);
  • }
    }
    }
  • for ( i=0; i < adaptors; ++i ) {
  • if (ainfo[i].name != NULL) Xfree(ainfo[i].name);

  • if (ainfo[i].formats != NULL) Xfree(ainfo[i].formats);
    }
  • Xfree(ainfo);
    if ( xv_port == -1 ) {
    SDL_SetError(“No available video ports for requested format”);
    return(NULL);
4

Yes - I’ve found this tool to be very helpful - doesn’t work well in real
time, though, and doesn’t support MMX.

I tried to bribe the Valgrind maintainer with promises of trying Serious
Sam (which refuses to run without MMX support) with his tool if he
implements MMX support, but I haven’t heard back yet. I blame the
Slashdotting. :slight_smile:

Here are some diffs for X11 and yuv. Note that the last part 2nd diff
should probably be a new call to XvQueryAdaptorFree with ainfo and the number of
adaptors, instead of the loop through like I did.

I’ve applied this to CVS, with a FIXME to come back and do the
XvQueryAdaptorFree() call later.

Thanks!

–ryan.

5

Here are some diffs for X11 and yuv. Note that the last part 2nd diff
should probably be a new call to XvQueryAdaptorFree with ainfo and the number of
adaptors, instead of the loop through like I did.

  • for ( i=0; i < adaptors; ++i ) {

  •   if (ainfo[i].name != NULL) Xfree(ainfo[i].name);

  •   if (ainfo[i].formats != NULL) Xfree(ainfo[i].formats);
}

This chunk here is segfaulting SMPEG on my system (but it runs under
Valgrind…how odd.) Is anyone else seeing similar problems with other YUV
surfaces? I’ll back this patch out if we can’t figure it out in short
order.

(Valgrind has a field day with SMPEG, btw…I’ll need to do some cleanups
in there when I get a chance.)

–ryan.

6

(Valgrind has a field day with SMPEG, btw…I’ll need to do some cleanups
in there when I get a chance.)
How did you get valgrind to run the application? All I manage to get with my
app or plaympeg is a seg fault.

My app loses about 12k for every mpeg it plays using smpeg, although this
seems dependent on the actual mpeg played.

Paul.>

–ryan.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

7

(Valgrind has a field day with SMPEG, btw…I’ll need to do some cleanups
in there when I get a chance.)

How did you get valgrind to run the application? All I manage to get with
my app or plaympeg is a seg fault.
I just discovered you can’t run an app as root, well I can’t seem to anyway.On Sat, 3 Aug 2002 18:51, you wrote:

My app loses about 12k for every mpeg it plays using smpeg, although this
seems dependent on the actual mpeg played.

Paul.

–ryan.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl