See this forum thread: http://forums.gentoo.org/viewtopic-t-907948.html In the first place, it could be fixed (?) by rebuilding all packages depending on sip and PyQt4. At some point this did not help anymore. So now there must be an error within the wrapper-code, introduced together with kde-4.6.5 (I assume). For me the error does not occur everytime, but there seem to be users, who never succeed in loading the printer settings. When loading fails, systemsettings uses 100%, stays unusable. Backtrace shows, it hangs in qt_plugin_instance() from kpythonpluginfactory.so. The wrapper also can't be loaded by QPluginLoader. Trying so results in an error: "The file '/usr/lib64/kde4/kpythonpluginfactory.so' is not a valid Qt plugin." Reproducible: Always
Created attachment 306945 [details] first test using kservicetypetrader This test loads the factory as done in systemsettings, using KServiceTypeTrade. Save as main.cpp, edit it and replace "Druckereinrichtung" with the name in your language found in /usr/share/kde4/services/system-config-printer-kde.desktop, then compile with g++ main.cpp -o main -I/usr/include/KDE/ -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -lQtCore -lkdecore -L/usr/lib64/qt4 -lQtGui Run it several times, it locks up regularly, making ./main using ~100% CPU.
Created attachment 306949 [details] second test using klibrary As QPluginLoader does not load kpythonpluginfactory.so, it will go and use KLibrary, see KPluginLoader::load() and KPluginLoader::factory(). (The usage of KLibrary is marked as deprecated in KPluginLoader, so at some point the kpythonpluginfactory-wrapper won't load anymore!!!) Compilation works with the above command, but replace the filename with yours. It will lock, too! So this really is a problem inside the wrapper-plugin!
Created attachment 306951 [details] Oops... first test, again. Somehow, there got a "->library()" pasted in, so did not compile...
I just modified kpythonpluginfactorywrapper.c to print the name of the library passed to dlopen. When everything goes fine, it is /usr/lib64/kde4/kpython2.7pluginfactory.so. When the app gets stuck (that is an infinite loop in qt_plugin_instance inside the wrapper-plugin) I only get /usr/lib64/kde4/kpython2.7 When everything goes fine, "length" is 46, if it fails, "length" is 47. There is an additional "\n" at the end of the version string! That must be stripped away and everything should run fine. The attached patch removes the first "\n" (I am not sure about the break, because it terminates after the first occurrence - counld it be, that the string starts with "\n"? I don't think so.) It also fixes the name hiding of "handle" inside init.
Created attachment 307237 [details] Patch to fix the version string
Tracking upstream will not help, as this is solely a gentoo-issue. kpythonpluginfactorywrapper.c is in "${PORTDIR}/kde-base/pykde4/files". It was introduced on 9th of july 2011: *pykde4-4.6.5-r1 (09 Jul 2011) 09 Jul 2011; Alexey Shvetsov <alexxy@gentoo.org> +pykde4-4.6.5-r1.ebuild, +files/kpythonpluginfactorywrapper.c: Version bump KDE SC 4.6.5 And inside this wrapper is the problem: execv seems to append "\n" sometimes. If that is an issue with execv, it should get addressed, for sure. At least, the patch fixed the problems for me and two other users: http://forums.gentoo.org/viewtopic-p-7000176.html#7000176
As i can see from forum entries 4.7.4 is affected too, so it cant block the stabilization.
(In reply to comment #6) > And inside this wrapper is the problem: execv seems to append "\n" > sometimes. If that is an issue with execv, it should get addressed, for sure. > At least, the patch fixed the problems for me and two other users: > http://forums.gentoo.org/viewtopic-p-7000176.html#7000176 issue solved at my almost stable x86 system with KDE 4.8.3 too
Could we get this fixed? Recent update to kde-4.8.4 broke it again. As I did not use the system-config-printer-thing, I did not really care about this - and forgot about the problem. Some days ago I wrote some krunner-plugins for a friend of mine, and he now blames me that everything got so slow. It turned out it was krunner spiking at 100%, because of this bug. Toralf closed the upstream bug, so can this (or a similar) patch get merged? Thx!
In overlay for testing: http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commitdiff;h=4fdfe5d4647b2f536ea2c55404a089e3af7b1946
Thanks for the patch Franz, this is in CVS for 4.9.0 and will be with 4.8.5 too.
