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

[Adrien Bustany]

On Sun, 08 Feb 2009 09:54:53 +0000, Richard Hughes <hughsient at gmail.com>
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.
> 
> 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.
> 

Hi,
I'll investigate this problem, and probably add a new error code in the
enum like the glib lib does...

Thanks for reporting the problem

Adrien

> Richard.
> 



> 
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit