On Monday 27 August 2012 22:15:18 Daniel Nicoletti wrote: > 2012/8/27 Christoph Feck <christ...@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"? > 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 ... > 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 ;) The only problem I see is with triaging. I stopped resolving as a direct duplicate long ago, in order not to flood hundreds of reporters for each additional duplicate, but I do not like this solution (duplicates.cgi still counts them, though). > Best, > Daniel
