[pulseaudio-discuss] asserts active by default

[Lennart Poettering]

On Tue, 02.09.08 19:20, Jan-Benedict Glaw (jbglaw at lug-owl.de) wrote:

> On Tue, 2008-09-02 18:01:20 +0200, Lennart Poettering <lennart at poettering.net> wrote:
> > On Tue, 02.09.08 14:58, Jan-Benedict Glaw (jbglaw at lug-owl.de) wrote:
> > > But pulse behaves different here. A lot of circumstances where
> > > everybody and her turtle would just return an error, pulse will hit an
> > > assertion.
> > 
> > "Just return an error"?
> > 
> > In the PA core I use asserts wherever a programming error is
> > obvious. Which is the right thing to do. (Note that I am am talking of
> > the core here, not the client libs!)
> 
> Please keep in mind that traditionally, assert() is only used during
> the testing phase. NDEBUGging it out of the code should still give you
> a working program that behaves just right[tm]. An assert() is a
> construct to be used as a pessimistic check in a paranoid world to
> check something that should never ever happen.

Yes, PA still works fine with NDEBUG. I wouldn't recommend running it
that way. I tried to make clear that pa_assert() is really only used
for redunant checks that can safely be disabled. only pa_assert_se()
needs to be kept around.

> > It is naive to believe that "just returning an error" would be a good
> > option in all cases including programming errors in complex programs
> > like in PA. Error paths can never be tested comprehensively, which
> 
> Dump a stacktrace, use fprintf(), ...

pa_assert() won't dump a bt right-away. However it calls abort() which
usually indicates debuggers to dump a trace. And pa_assert uses
pa_log_error() which is even better than fprintf(). It's output is no
pretty human readable string, but a C expression. But that's fine,
since this it just explains a programming error, which cannot be fixed
by the user anyway and needs to be fixed upstream.

> > means they are usually much more buggy than the paths where everything
> > is behaving correctly. Which means: if it is you who fucked up, then
> > admit it, don't try to fuck it up even further by trying to be smart
> > and come up with "Plan Bs" or something that try to fix your
> > programming errors without you even knowning them. The crux of
> > handling programming errors is that you can never know what their nature
> > actually is. Because if you new, you'd have fixed them anyway, right?
> 
> Sure.  Though that doesn't actually imply killing the program, after
> being build with standard options, while it could detect and handle
> error situations that could be handled by a simple return -1.

Dude, please read again what I alredy wrote.

> > Catching common-case runtime errors is hard enough. Spend your time on
> > coming up with error paths for them. Don't try to come up with errors
> > paths for your own programming errors! Spend the time of fixing them
> > instead.
> 
> Sure. That's where you first have an assert() to simply drop into the
> GDB prompt during the devel phase, and a regular if (...) check right
> afterwards, containing the traditional error handling.
> 
> Note that this doesn't neccessarily hold true for /all/ cases of
> assert() usage. I'm not suggesting, in any way, to just substitute
> assert()s by if()s.

Ah, hear hear.

As I already mentioned PA uses assert()s only for programming
errors. Runtime errors that can be expteced are handled properly. Such
as IO, disk full, permission, blah blah.

> > > 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, ...)
> > 
> > malloc() returning NULL is not an error that can realisticly
> > happen. If malloc() returns NULL you are fucked anyway.
> 
> It can easily happen if you eg. switch off memory overcommit. 
 
Sure. But nobody would seriously try to do that -- unless you work on
embedded real-time devices. PA is not designed for unpaged, shm-less MMU-less
devices. (Didn't we have this topic on the ML already a week ago?

> On top of that, this situation can even clear within some
> milliseconds.

Sure, and?

> > Due to this all reasonable software (unless it is very low-level or
> > kernel stuff) doesn't try to handle OOM. It just aborts. All GLib/Gtk
> > programs are one example. PA is another one.
> 
> Database systems, or any software working with large datasets (large
> enough that they could hit the address space constraints), are a
> counter-example. They *rely* on overcommit being switched off.

Fpr database software where you really might hit the address space
limits you use 64bit processors anyway, where they practially don't
apply anymore.

And don't forget. PA is no database software. It's just an audio
daemon. 

Lennart

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