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

[Tanu Kaskinen]

On Wed, 2012-05-09 at 17:12 +0200, Dalleau, Frederic wrote:
> > What triggered this was a question about what to do if BlueZ claims that
> > there are two devices with the same address (that should never happen).
> > I'd like to store the devices in a hashmap with the address as the key,
> > so there are complications if there are multiple devices with the same
> > address. Those complications can be avoided, if I do just:
> >
> > pa_assert_se(pa_hashmap_put(bluetooth_core->devices_by_address, device->address) >= 0);
> >
> > Why should I implement any more complex error handling?
> 
> The error handling don't have to be necessarily complex (goto fail?).
> And the use of an assertion creates the perception that PulseAudio has
> crashed, whereas in this case (if it ever happened) the bug would not be
> in pulse.
> 
> Let's put the question another way : What is the benefit at not being
> paranoid?

The benefit is simpler code.

It's clearly not a very popular idea to add assertions about D-Bus
service behavior. I'll forget about it then. It shouldn't be a big
burden to add the necessary message validation checks. If there is
clearly invalid stuff in the messages, I'll just ignore the message and
log an error: "The same address is assigned to multiple devices. This
may be a bug in BlueZ. In any case, the Bluetooth functionality probably
won't work very well."

Also, I think I now finally understood David's point about libraries'
ability to corrupt the process memory: incorrectly behaving libraries
undermine the trust in all of the process memory in a way that buggy
D-Bus services can't do. Therefore there's less reason with D-Bus
services for just giving up and aborting if something unexpected
happens.

-- 
Tanu