[pulseaudio-discuss] asserts active by default
lennart at poettering.net
Tue Sep 2 09:22:11 PDT 2008
On Tue, 02.09.08 16:23, Colin Guthrie (gmane at colin.guthr.ie) wrote:
> Yeah, perhaps less assertions would be better. But that said, it's very
> easy not to check a return value or implement sloppy error handling.
> It's impossible to ignore an assert. But if audio output is just part of
> your app and you can live without it, then having the whole app brought
> down by this is a bit annoying I agree.
Again, the asserts in the PA client code catch *internal* programming
errors or unfixable errors (like bad memory access, double free...).
For programming errors as in "a client misuses the PA API" we return
proper error codes.
> > Right, because error handling and assertions were mixed up. Error
> > handling is for errors that could expectedly happen (eg. malloc()
> > returns a NULL pointer, user requests an operation that's invalid in
> > this context, ...)
> So when malloc fails, you should be able to recover? I would have
> thought that if malloc fails you're pretty much screwed, no?
The whole OOM story brought up here reminds me of that fool who posted
this ubuntu forum post a while back:
Handling OOM in userspace programs is a lost cause. Also see Havoc's
post on this:
> I mean if you cannot allocate memory then how are you going to compile a
> string to display to the user what's wrong? (Unless you keep a
> pre-malloced error buffer around I guess).
There's always the stack...
if you overflow the heap, you will be killed by the OS OOM killer (at
least there's a big chance that it identifies you as the culprit...)
if you overflow the stack (i.e. RLIMIT_STACK) you get a SIGSEGV by the
If you really want to have a buffer for printing an error message
from, then you need to allocate it in advance and mlock() it so that i
never gets swapped away.
> > But I may be wrong here, too :)
> Well if that's true (I'm sure Lennart will issue a correction if it's
> not ;)), then this doesn't really hold water. As libcanberra is used in
> *all* GTK apps and it can, in theory, hit an assert via it's pulseaudio
> output then it has the power to take down any application, not just
> "playing audio".
> I can certainly see the argument that if an assert is hit as a result of
> something in libcanberra then there is no reason at all to crash the
> whole app.
In C land an error in a library always has the power to bring you
whole process down. If you manage to hit an assert in PA or
libcanberra, then you found a programming error.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss