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

[Trever Fischer]

On Sunday 08 February 2009 04:54:53 am Richard Hughes wrote:
> 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.
Adding a 'getError' method of sorts to the Client class would be the Qt 
equivalent of this. Then, we can just return NULL for all the methods when 
something fails, and set getError to return a value like StartupError, 
PermissionError, or UnsupportedError.

> 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.
I think handling both errors in the library takes the load off of the GUI 
developer of having to make sure the library won't crash. KPackageKit simply 
does this kind of code to check for an error:

Transaction* t = Client::updateSystem();
if (t) {
  //Started!
} else {
  //Didn't start.
}
>
> Richard.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20090208/d4ee0e3d/attachment-0004.pgp>