SDL Audio Memory Errors

I tried playing around with SDL_Audio, and ran into some memory corruption
issues. For example, a simple program such as:

#include “SDL/SDL.h”
#include “SDL/SDL_mixer.h”
#include "SDL/SDL_main.h"
int main()
{
SDL_Init(SDL_INIT_AUDIO);

SDL_Quit();
return 0;
}

compiled with
g++ -g tryaudio.cpp sdl-config --cflags --libs -lSDL_mixer
and run with
valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes a.out

gives numerous memory leaks AND ERRORS. Any idea if these are serious?

Thanks much for your time.
–Shree

valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes a.out

gives numerous memory leaks AND ERRORS. Any idea if these are serious?

With Valgrind, you should start by fixing the really bad things, then
making your way toward the more subtle and less certain problems. So I
recommend you just run it without the leak checking, and only pay
attention to the errors (those have a very low false positive rate,
they’re most likely real bugs in the code). Then, you can add
"–leak-check=full", and once you believe you’ve dealt with the new
warnings, only then add “–show-reachable=yes”.

For example, something that is fairly common is allocating memory the
first time some function is called, assigning it to a global pointer,
re-using the same memory afterward, then letting the operating system
clean up, rather than explicitly free the memory. This is correct, and
is not a real memory leak (if the program runs a long time, it will
not consume an increasing amount of memory over time). A block of
memory used in this way would be still reachable (through the global
variable) at the end of the program.

By the way, “–tool=memcheck” is the default, no need to specify it.On Tue, Jun 2, 2009 at 1:06 AM, shree 0987 wrote:


http://pphaneuf.livejournal.com/

Pierre,

I understand that Valgrind will show me a bunch of stuff that I could
investigate later. But with such a simple program, I would expect zero
errors. When I run as you suggest (without leak checking), I get:

==26419== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 69 from 2)
==26419==
==26419== 2 errors in context 1 of 1:
==26419== Syscall param semctl(IPC_SET, arg.buf) points to uninitialised
byte(s)
==26419== at 0x40007D2: (within /lib/ld-2.8.90.so)
==26419== by 0x4430183: (within /usr/lib/libasound.so.2.0.0)
==26419== by 0x4428782: snd_pcm_dmix_open (in /usr/lib/libasound.so.2.0.0)
==26419== by 0x44291CC: _snd_pcm_dmix_open (in /usr/lib/libasound.so.2.0.0)
==26419== by 0x43F3351: (within /usr/lib/libasound.so.2.0.0)
==26419== by 0x43F3AAC: (within /usr/lib/libasound.so.2.0.0)
==26419== by 0x43F3BAF: (within /usr/lib/libasound.so.2.0.0)
==26419== by 0x4433C7D: _snd_pcm_softvol_open (in
/usr/lib/libasound.so.2.0.0)
==26419== by 0x43F3351: (within /usr/lib/libasound.so.2.0.0)
==26419== by 0x43F3BE5: (within /usr/lib/libasound.so.2.0.0)
==26419== by 0x441090C: _snd_pcm_plug_open (in /usr/lib/libasound.so.2.0.0)
==26419== by 0x43F3351: (within /usr/lib/libasound.so.2.0.0)
==26419== Address 0xbec28bac is on thread 1’s stack
–26419–
–26419-- supp: 4 dl-hack5-32bit-addr-1
–26419-- supp: 65 dl-hack3-cond-1
==26419==
==26419== IN SUMMARY: 2 errors from 1 contexts (suppressed: 69 from 2)

–Shree

I understand that Valgrind will show me a bunch of stuff that I could
investigate later. But with such a simple program, I would expect zero
errors. When I run as you suggest (without leak checking), I get:

==26419== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 69 from 2)
==26419==
==26419== 2 errors in context 1 of 1:
==26419== Syscall param semctl(IPC_SET, arg.buf) points to uninitialised
byte(s)

That’s a good example of one of those rare false positives. The
content pointed at by arg.buf is not all used, only certain parts, but
Valgrind sees a system call that takes a struct of a certain size be
passed in, and that only some bytes are actually initialized, so it
calls it out, because it doesn’t necessarily knows that the fields
needed for that particular call are all initialized.

For those cases, using a suppression file entry is probably your best bet.On Tue, Jun 2, 2009 at 4:17 AM, shree 0987 wrote:


http://pphaneuf.livejournal.com/

The first thing I noticed is that the error occurs in libasound, not
in code that is part of the SDL code base. Have you verified that the
error is the result of a parameter created in SDL? That is, is there
anything the maintainers of SDL could possibly do the correct the
error?

Bob PendletonOn Tue, Jun 2, 2009 at 3:17 AM, shree 0987 wrote:

Pierre,

I understand that Valgrind will show me a bunch of stuff that I could
investigate later. But with such a simple program, I would expect zero
errors. When I run as you suggest (without leak checking), I get:

==26419== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 69 from 2)
==26419==
==26419== 2 errors in context 1 of 1:
==26419== Syscall param semctl(IPC_SET, arg.buf) points to uninitialised
byte(s)
==26419== at 0x40007D2: (within /lib/ld-2.8.90.so)
==26419== by 0x4430183: (within /usr/lib/libasound.so.2.0.0)
==26419== by 0x4428782: snd_pcm_dmix_open (in /usr/lib/libasound.so.2.0.0)
==26419== by 0x44291CC: _snd_pcm_dmix_open (in /usr/lib/libasound.so.2.0.0)
==26419== by 0x43F3351: (within /usr/lib/libasound.so.2.0.0)
==26419== by 0x43F3AAC: (within /usr/lib/libasound.so.2.0.0)
==26419== by 0x43F3BAF: (within /usr/lib/libasound.so.2.0.0)
==26419== by 0x4433C7D: _snd_pcm_softvol_open (in
/usr/lib/libasound.so.2.0.0)
==26419== by 0x43F3351: (within /usr/lib/libasound.so.2.0.0)
==26419== by 0x43F3BE5: (within /usr/lib/libasound.so.2.0.0)
==26419== by 0x441090C: _snd_pcm_plug_open (in /usr/lib/libasound.so.2.0.0)
==26419== by 0x43F3351: (within /usr/lib/libasound.so.2.0.0)
==26419== Address 0xbec28bac is on thread 1’s stack
–26419–
–26419-- supp: 4 dl-hack5-32bit-addr-1
–26419-- supp: 65 dl-hack3-cond-1
==26419==
==26419== IN SUMMARY: 2 errors from 1 contexts (suppressed: 69 from 2)

–Shree


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------

The first thing I noticed is that the error occurs in libasound, not
in code that is part of the SDL code base. Have you verified that the
error is the result of a parameter created in SDL? That is, is there
anything the maintainers of SDL could possibly do the correct the
error?

I would guess there probably isn’t, and that if it is truly a bug, it
would be a bug in libasound.On Tue, Jun 2, 2009 at 9:26 AM, Bob Pendleton wrote:


http://pphaneuf.livejournal.com/

shree 0987 wrote:

I understand that Valgrind will show me a bunch of stuff that I could
investigate later. But with such a simple program, I would expect zero
errors. When I run as you suggest (without leak checking), I get:

Valgrind does a complicated job. It is a complicated tool.

In order to use Valgrind effectively, one needs to understand what it is
doing and how it does it. Both of these are outlined quite clearly in
Valgrind manual.

One of the first sections in the manual (Section 2.5 if you must know)
discusses suppression of errors, specifically, that

“The error-checking tools detect numerous problems in the base
libraries, such as the GNU C library, and the X11 client libraries,
which come pre-installed on your GNU/Linux system.”

And goes on to say:

“You can’t easily fix these, but you don’t want to see these errors
(and yes, there are many!)”

This is the answer to upwards of 95% of questions regarding Valgrind and
SDL.

More experienced developers can usually understand when someone hasn’t
delved to the deepest, darkest depths of a manual, but when there has
been no attempt to read the introduction and first chapter proper, it
will usually generate the clich? response: RTFM.

I like to at least try to be original, so I’ll say this instead:

ALRCOOTFM (At Least Read Chapter One Of The Manual)

Much Lav,

Eddy

Most responses to this query say it is “probably a false-positive from
Valgrind”. But I would like someone to categorically tell me it really is
so. Better yet, how to fix it.

My company is building a consumer product, and there’s no way to patch the
software once we’ve sold the boxes. We’re a small startup, and if we get
this wrong, we’re sunk. So forgive me if I’m being paranoid about this.

What’s a good place to find out about libasound memory errors?

Thanks,
–Shree.

What’s a good place to find out about libasound memory errors?

Get the source, recompile it with debug info, and use your version to
run your program on Valgrind. Hopefully you’ll get the same error, and
you’ll be able to see the exact line of code, and verify that it is
indeed initializing all that is necessary.

You could shut it up with a memset of the whole structure, but that
can be misleading: if there genuinely is a member that is not
initialized, that bug will remain, it will just become more
deterministic (instead of being random junk, it will be whatever you
put with the memset).On Wed, Jun 3, 2009 at 9:28 AM, shree 0987 wrote:


http://pphaneuf.livejournal.com/

shree 0987 wrote:

Most responses to this query say it is “probably a false-positive from
Valgrind”. But I would like someone to categorically tell me it really
is so. Better yet, how to fix it.

Um… it’s not a false-positive, it’s an error. Does that error
matter? I don’t know it’s your product. That’s only a decision you can
make.

My company is building a consumer product, and there’s no way to patch
the software once we’ve sold the boxes. We’re a small startup, and if we
get this wrong, we’re sunk. So forgive me if I’m being paranoid about this.

Hmm… then maybe you should engineer-in a method of updating your
product? Sorry if this sounds harsh, but do you actually have any idea
what you’re doing? I’m by no means an expert (I’ve only been in the real
world for a couple of years), but the kind of questions you’re asking
are ringing alarm bells in a big way. If this product is so risky, is
it the basis of a viable business? Does the reward warrant the risk?
Clearly, starting a business is inherently risky, but the sort of stuff
you’re asking about, makes me wonder if you’ve done your homework - are
you trying to develop something that other have already created? Are you
able to match them for price/differentiate yourself sufficiently to be
successful? Is there even a market for your product?

What’s a good place to find out about libasound memory errors?

When you run & test your program, do you get audio errors
(popping/clicking)? Do you get seg-faults emanating from libasound? Have
you interrogated the ALSA developers?

Good luck, sounds like you’re gonna need it…

Eddy

Most responses to this query say it is “probably a false-positive from
Valgrind”. But I would like someone to categorically tell me it really
is so. Better yet, how to fix it.

Um… it’s not a false-positive, it’s an error. Does that error
matter? I don’t know it’s your product. That’s only a decision you can
make.

The thing with false positives is that they, uh, say that they are
positives (errors). :slight_smile:

Think of the stat() system call, to which you pass a pointer to a
buffer that the kernel will fill out. That’s the whole idea of that
call: you get information out of the kernel, whatever is in that
structure will get overwritten.

For Valgrind, if it’s not “taught” about that particular system call,
it has no choice: it seems a pointer to a memory area going in, and if
it’s not initialized, it doesn’t know whether it’s okay or not, so it
gives an error. In the case of stat(), it would be a false positive.

In order to figure out if it’s a false positive or not, you have to
know what the system call does, and how it’s being used. It’s a good
idea to double-check, because Valgrind is usually right, but due to
the nature of the userspace/kernelspace boundary, it can’t know for
sure, so…On Sun, Jun 7, 2009 at 8:00 PM, Edward Cullen wrote:


http://pphaneuf.livejournal.com/

Thanks Pierre and Eddy for your help. I’ll try compiling libasound and
reproduce the error.

–Shree.