[pulseaudio-discuss] asserts active by default

[Lennart Poettering]

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:

http://ubuntuforums.org/showthread.php?t=612606

Handling OOM in userspace programs is a lost cause. Also see Havoc's
post on this:

http://log.ometer.com/2008-02.html

> 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
kernel.

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4