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
