[packagekit] PackageKit-qt crashes when the daemon fails to start

[Richard Hughes]

On Sun, 2009-02-08 at 02:15 -0500, Trever Fischer wrote:
> According to a bug reported against KPackageKit 
> (http://bugs.kde.org/show_bug.cgi?id=183565) a few days ago, PackageKit-qt can 
> crash a program when packagekitd doesn't startup right. To be a bit more in-
> depth, it asks the daemon to make a new transaction, and starts tossing around 
> a null transaction ID. The failure to start can be because of some invalid 
> default backend, or just a regular segfault.

Right, both of which are bad.

> So, what would be the best way to handle this situation? Have the library 
> return some error about it not starting? Have the daemon give a more specific 
> error signal about why it couldn't start (if it can live that long)?

Well, I think the daemon already does -- there's a limit what it can
pass due to dbus-system activation limitations, but it should
pass /something/. You then need to catch this error and throw an
exception.

> I think adding some method to the Client class to ping the daemon and see if 
> it is up and making all the transaction-generating methods return NULL if it 
> isn't up would be a good solution.

You don't want to introduce startup latency in the GUI tools.

> Another solution would be adding a check to 
> see if daemon->GetTid() is null in ClientPrivate::createNewTransaction() and 
> return NULL from there. Either way, the NULL eventually gets sent back up out 
> of the library.

Right, but what does NULL really mean? You need context.

> Regular authentication error checking would catch it, but then 
> we're using the same error condition for two totally different errors.

Right, when you setup the transaction, make it clear the method can fail
and that SomeError will be thrown. In the GLib library, in PkClient and
PkControl, we return false and set the GError to a local domain, a
DAEMON_CANNOT_START error code, and the geeky error in the message.

I don't see a problem in making GUI applications catch setup errors, as
even if you do GetUpdates when the daemon doesn't support it, it should
also return an error and be handled in the the GUI rather than crash.

Richard.