[pulseaudio-discuss] Is it OK for PulseAudio to crash when BlueZ is buggy?

[David Henningsson]

2012-05-09 00:19, Tanu Kaskinen skrev:
> Hi,
>
> While writing code, I've used a rule that if a library that we use is
> buggy (acts against its documentation), it's OK to crash in an
> assertion. For example, I've used a lot of assertions on libdbus calls
> that, according to the documentation, can fail only if there's not
> enough memory. Since PulseAudio handles OOM by aborting, it's OK to
> abort also when those libdbus calls fail. If they fail for some other
> reason than OOM, that's then against the documentation, and the correct
> course for action is to fix the bug in libdbus (or its documentation),
> not to work around the problem by adding recovery code in PulseAudio.
>
> I've also used a rule that buggy D-Bus services (and sound card drivers)
> that PulseAudio relies on shouldn't be able to crash PulseAudio, unlike
> buggy libraries. I can't really explain to myself why I've made that
> distinction between libraries and D-Bus services. I think it should be
> OK to assume that D-Bus services are working as documented, and when
> there are problems with that, fix the bug where it is.
>
> Opinions?

I tend to think about drawing the line at the process. Libraries can 
access process memory, if they are buggy, they can overwrite pointers 
inside pulseaudio, causing PulseAudio to crash and do other crazy stuff, 
and there is nothing we can do about that (except fixing the bug in the 
library).
Things out of process context, such as data coming from badly behaving 
clients, should be correctly verified, and errors given back when they 
fail.

If we draw the line there, things you access over dBus would then be out 
of process, and should then be properly verified. But as these error 
paths are seldom tested anyway, I guess it's okay to be a bit pragmatic 
about it - if you know that the particular dBus service is of good 
quality and has served you well for a longer period of time, I guess one 
could relax the restriction a bit and allow a few asserts here and 
there, at least for the most uncommon errors. For the Bluez dbus 
service, I think it's relatively new and under active development (or is 
it? correct me if I'm wrong here!), so it would not fall under this 
category of "relaxed checking" at all.

// David