KCM Authorization (was: Re: Review Request: print-manager on kdereview)

[Daniel Nicoletti]

2012/8/27 Christoph Feck <christoph at maxiom.de>:
> On Monday 27 August 2012 22:15:18 Daniel Nicoletti wrote:
>> 2012/8/27 Christoph Feck <christoph at maxiom.de>:
>> > I am talking about whatever design mistake is responsible for bug
>> > 242648, which isn't about CUPS at all. Sorry for side-tracking
>> > this thread. I was just thinking that with your expertise on the
>> > authorization-related stuff, we could plan better for the
>> > future, so that we don't carry this bug over to frameworks.
>>
>> Ah ok, it's a completely different issue. Now from the backtrace
>> you already know the issue is due to event loops, I didn't look
>> further but the bugs I had with Apper is because SystemSettings
>> call accept on the open module, then the accept opens an event
>> loop (otherwise returning will close SystemSettings).
>
> You already lost me here. What do you mean with "call accept on the
> module"?

I'll try to make it clearer:

acceptButton->click();
on_accepted_clicked() {
    currentModule->accept();
}

okButton->click();
on_accepted_clicked() {
    currentModule->accept();
    quit();
}

So to avoid the application quiting modules that need to perform
async tasks like talking to polkit or installing packages (Apper),
they need to create an event loop so that current module accept()
doesn't return (if it does quit() will be called).

So the user clicks Apply, while setting the time or doing anything
the user clicks to close the window, the event loop will return
and some stuff will be already deleted which causes the crashes...

>> So to fix this I maybe on KAuth or in SytemSettings a QPoiter
>> needs to check if the event loop is valid. Maybe the KCM could
>> pass an event that can be event->accept() to avoid blocking the
>> call with an event loop.
>
> Actually, I was always thinking the bug was because there was no
> blocking. If I follow the bug descriptions correctly, it looks like
> people can close System Settings, without the password dialog going
> away, because it is a separate process that isn't informed by KAuth
> framework while it waits for input. But maybe I am talking stuss ...

Yes, the big problem is the user closing SS, because the event loop
will return immediately.

>> This is going a bit out of the scope of the thread but if you want
>> I can take a closer look to the issue.
>
> No need to hurry, it's only 210 duplicates, which is far from crash #1
> with 322 duplicates ;)
hehe well that's a lot of dups, quite boring to keep marking,
unfortunately I'm trying my best to get my commercial app ready to
be sold, so time is short, but if you look at Apper KCM save()
you will see some QPointers to make sure it doesn't crash anymore...

Best,

--
Daniel Nicoletti

KDE Developer - http://dantti.wordpress.com