Re: Fatal warnings in client code
Thiago Macieira <[email protected]> Mon, 06 Mar 2023 11:41:17 -0800
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Message-ID | <3670283.MHq7AAxBmi@tjmaciei-mobl5> |
On Monday, 6 March 2023 05:16:11 PST Simon McVittie wrote: > With DBUS_FATAL_WARNINGS=0 or if "checks" were disabled at build time, > the typical result of attempting to send invalid D-Bus messages is that > message validation will fail in the message bus instead of in the client, > resulting in the client being unceremoniously disconnected. And this is very important. The message will not reach the destination and moreover the client will be disconnected. Most applications will not survive the bus disconnection; in fact, we've designed it so that a bus disconnection usually imply the session is ending and thus the application should exit. Those that do ask not to be automatically exit-on-disconnect do so anyway, just with a nicer clean up path. Surviving the disconnect requires careful coding so that the state that was shared with the bus peers is discarded and the application no longer tries to send on D-Bus. By definition, if the application got disconnected because it sent invalid data, it's a buggy application. On the debugging side, it's far easier for the developer to debug when they have the crash dump from the point where the validation failed, so they can see the message that was sent and often where it was sent from. Debugging why the bus disconnected this application requires finding the last few messages that have already been sent, which more often than not requires logging ALL messages from the application start... and may hide the problem in the first place by not including the actual invalidity in the log itself. In an ideal world, the application shouldn't have to check what it is sending. In practice, as this particular case have shown, applications are buggy.