Bug 220403

I don't get a crash, but it does say that the authentication failed and pops up a dialog asking for my password.

Is this a bug for you drf?

Please try using the latest polkit-qt release (as found on http://dot.kde.org/2009/12/25/kde-extends-polkit-support-polkit-1 ). Unfortunately on Qt 4.6 that release is needed to fix this kind of behavior (and in fact 4.4 trunk depends on it)

Carth (the reporter),
  Is it possible for you to upgrade to the latest polkit-qt and check for the bug again?

I installed this RPM from Mandriva:

lib64polkit1_0-0.95-1mdv2010.1
polkit-gnome-0.95-1mdv2010.1
polkit-kde-1-debug-0.95.1-1mdv2010.1
polkit-qt-devel-0.9.3-1mdv2010.1
polkit-qt-debug-0.9.3-1mdv2010.1
lib64polkit-qt-agent-10-0.95.1-1mdv2010.1
polkit-kde-1-0.95.1-1mdv2010.1
lib64polkit-qt-core0-0.9.3-1mdv2010.1
polkit-qt-1-devel-0.95.1-1mdv2010.1
lib64polkit-qt-core-10-0.95.1-1mdv2010.1
lib64polkit-devel-0.9-6mdv2010.0
polkit-qt-1-debug-0.95.1-1mdv2010.1
polkit-debug-0.95-1mdv2010.1
lib64polkit-qt-gui0-0.9.3-1mdv2010.1
lib64polkitkdeprivate4-4.3.85-2mdv2010.1
lib64polkit1-devel-0.95-1mdv2010.1
lib64polkit2-0.9-6mdv2010.0
lib64polkit-qt-gui-10-0.95.1-1mdv2010.1
lib64polkit-gnome0-0.9.2-4mdv2010.0
polkit-0.95-1mdv2010.1

But KRunner is crashed again. May be this bug belongs to Mandriva.

Now that I look again at your bug, yes, it's an upstream bug. This is not a crash, more than a forced quit due to a failed assert. The interested line is the following:

Q_ASSERT_X(auth, __FUNCTION__, "No AuthBackend found.");

Which, of course, should never happen. I suppose it's a packaging problem.

upstream is Mandriva?  What should they fix exactly?  I don't see how marking this as closed helps anything?

John, it's a packaging bug. And it's unrelated to KSysGuard. I'm marking it as closed because I can't fix packaging mistakes.

I get that.  But what is the packaging bug?  Where is it?  It is a packaging bug with policy-qt?  With policy-kit?  With ksysguard?  How can it be fixed?

*** Bug 221268 has been marked as a duplicate of this bug. ***

Hum, so we still don't have an actual solution for this, right?  We think it's a packaging bug, but have no idea what package or how to fix?

*** Bug 222419 has been marked as a duplicate of this bug. ***

i don't see where is the packaging but here. i reproduce with kde 4.3.90 and with polkit qt isntalled.


what missing part could lead to this assert ?

Well if polkit-qt isn't installed then I think it will most definitely crash.

There's a Q_ASSERT to make it crash if no backends are found :-/

yes but here it is installed and you can see in comment #4 that this is installed too.

Let me add some more details:

1 - The problem is not in polkit-qt being installed or not but more in how kdelibs was compiled and/or packaged. kdelibs generates a static plugin for KAuth which in this case is missing: in fact the assertion means that the static plugin in question is not found

2 - Due to this, this is not a bug in KDE, and I really don't know how to solve this or what hints to give, unless I know how Mandriva packages his stuff. It actually makes me wonder how this could happen, since the buildsystem ALWAYS builds a backend, eventually falling back to the fake one, so there should be something wrong somewhere

I am closing this bug again, and please do not open it again unless there is evidence that the problem lies in KDE. However I will be happy to give out some help on Mandriva's tracker.

(I got wrong before, distributions are downstream, thanks ossi ^^)

> in fact the assertion means that the static plugin in question is not found

Is it possible for me to check if the plugin is found?  I don't want ksysguard and krunner crashing if the plugins aren't found - I'd rather just gracefully disable that functionality and give an error.

Are there any unit tests for kauth btw?  From the first bug report it sounded like it could be triggered by trying to kill two processes rapidly.  It would be good to add a unit test for calling kauth twice in a row, just to check for this.

>Is it possible for me to check if the plugin is found?  I don't want ksysguard
and krunner crashing if the plugins aren't found - I'd rather just gracefully
disable that functionality and give an error.

No, because it's not a KService plugin. It is compiled inside kdelibs and it should be always present, unless you do some bad tricks

> Are there any unit tests for kauth btw?  From the first bug report it sounded
like it could be triggered by trying to kill two processes rapidly.  It would
be good to add a unit test for calling kauth twice in a row, just to check for
this.

I don't recall any unit test but the situation you explained is plain impossible, at least related to this bug, unless somebody initializes KAuth twice, which again is pretty much impossible. Also, the fact that this bug happens only on Mandriva is a proof that the problem lies there.

Could the function return false or something then instead, instead of crashing?

Could this bug be related:

https://bugs.kde.org/show_bug.cgi?id=224135

it's a segmentation fault instead, and it's with OpenSuse

>Could the function return false or something then instead, instead of crashing?

No, it's an assert notifying a missing component hence it's a critical error that has to lead to a crash. Straight to the point, it should simply never happen.

>Could this bug be related:

Probably. Knowing what backend those systems are using and the cmake line of kdelibs would probably help figuring out.

Hmm, 
https://bugs.kde.org/show_bug.cgi?id=222419

My bug report got marked as a duplicate of this bug. I'm op openSUSE though..

Could it be that this is the problem, in 

#ifndef KDE_USE_FINAL
Q_IMPORT_PLUGIN(auth_backend)
Q_IMPORT_PLUGIN(helper_proxy)
#endif

It sounds quite possible that Mandriva compiles with --use-final  to reduce
binary size, so these wouldn't happen.  Would bad things happen in such a case?

It's -DCMAKE_BUILD_TYPE=release not --use-final, but yeah, openSUSE builds with that too.

Thiago says that what Q_IMPORT_PLUGIN does is that it adds the statically-compiled plugin to QPluginLoader's list.

So it would indeed return an empty list of instances.

Talking to montel and thiago, the long term fix is to remove the whole static plugin code.  kdelibs code really should not be doing this.

In the short term, adding KDE4_NO_ENABLE_FINAL(kauth)  to CMakeLists.txt  should fix it.

Oh crap. I didn't commit that line and didn't realize that.

However, not so easy. The whole kdecore should actually be added to NO_FINAL, and I guess this is not acceptable. I can come up with something to avoid the need of having static plugins, still solid does that and it's in kdelibs.

However, I'm assigning this bug to myself and will try to remove the static plugins. If I come up with something acceptable I'll just commit straight away, otherwise we'll see.

After some additional reasoning and looking at the code again, I await for the issue to be discussed on k-c-d, since the change does not make a lot of sense and other code in kdelibs simply relies on static plugins.

to comment #22, yes we compile with enable final

*** Bug 224460 has been marked as a duplicate of this bug. ***

SVN commit 1081127 by dafre:

BUG: 220403

Switch KAuth backend probing to static code compilation without the use of Qt's static plugins. This has some nice side effects:

1. Compilation with KDE4_ENABLE_FINAL works again (see bug in question)
2. The asserts are no longer triggered (they're still there for beauty), since now an error at compile time would occur instead
3. The whole probing is slightly more reliable.

It all seems to work but I urge everyone to test since release is near.
I'm backporting this commit in minutes



 M  +11 -80    CMakeLists.txt  
 M  +0 -1      auth/AuthBackend.h  
 M  +29 -17    auth/BackendsManager.cpp  
 M  +87 -0     auth/ConfigureChecks.cmake  
 M  +0 -1      auth/HelperProxy.h  
 M  +3 -7      auth/backends/dbus/DBusHelperProxy.cpp  
 M  +1 -2      auth/backends/dbus/DBusHelperProxy.h  
 M  +0 -3      auth/backends/fake/FakeBackend.cpp  
 M  +0 -2      auth/backends/mac/AuthServicesBackend.cpp  
 M  +0 -3      auth/backends/policykit/PolicyKitBackend.cpp  
 M  +0 -2      auth/backends/polkit-1/Polkit1Backend.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1081127

SVN commit 1081133 by dafre:

CCBUG: 220403

Backporting r1081127



 M  +11 -80    CMakeLists.txt  
 M  +0 -1      auth/AuthBackend.h  
 M  +29 -17    auth/BackendsManager.cpp  
 M  +87 -0     auth/ConfigureChecks.cmake  
 M  +0 -1      auth/HelperProxy.h  
 M  +3 -7      auth/backends/dbus/DBusHelperProxy.cpp  
 M  +1 -2      auth/backends/dbus/DBusHelperProxy.h  
 M  +0 -3      auth/backends/fake/FakeBackend.cpp  
 M  +0 -2      auth/backends/mac/AuthServicesBackend.cpp  
 M  +0 -3      auth/backends/policykit/PolicyKitBackend.cpp  
 M  +0 -2      auth/backends/polkit-1/Polkit1Backend.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1081133

*** Bug 221937 has been marked as a duplicate of this bug. ***

*** Bug 222879 has been marked as a duplicate of this bug. ***