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

[Adrien BUSTANY]

Trever Fischer a écrit :
> 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.
>>     
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
>   

Hi Trever
please check the git version of PackageKit-Qt, those errors should be 
handled more gracefully.

Cheers
Adrien

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20090217/27ce687f/attachment-0004.htm>