We will need a stack trace from gdb attached to the bug report. Best way to do that is: 1.) Wait for the process to hang 2.) Switch to another console and find the PID of the hung process 3.) Start gdb with 'gdb' 4.) Issue these commands to gdb: a.) attach <PID you found above> b.) bt
gdb should now spit out a backtrace that can be attached to the bug report. You will of course need the debugging symbols installed for the backtrace to be of any use. ;-)
I don't know if I doing all of this correctly. I have two back traces. I don't know whether they are useful. I'll post them here because they are small. If they look useful then I'll attach them to the bug report.
============================ Attaching to the kconf_update process:
No stack. Attaching to process 23912
blah, blah...
0xb5dcb236 in ?? () from /usr/lib/libGL.so.1 #0 0xb5dcb236 in ?? () from /usr/lib/libGL.so.1 ============================
============================ Attaching to the kdetcompmgr process:
#0 0xb6a946ce in __waitpid_nocancel () from /lib/libc.so.6 #1 0xb75fd222 in my_system () at /dev/shm/kdelibs/kdecore/kapplication.cpp:1049 #2 KApplication::startKdeinit () at /dev/shm/kdelibs/kdecore/kapplication.cpp:1459 #3 0xb75fd77d in KApplication::dcopFailure (this=0xbfabf1fc, msg=...) at /dev/shm/kdelibs/kdecore/kapplication.cpp:1471 #4 0xb7605022 in KApplication::qt_invoke (this=0xbfabf1fc, _id=16, _o=0xbfabe800) at /dev/shm/kdelibs.build/kdecore/kapplication.moc:279 #5 0xb7088de5 in QObject::activate_signal(QConnectionList*, QUObject*) () from /opt/trinity/lib/libqt-mt.so.3 #6 0xb708b11f in QObject::activate_signal(int, QString) () from /opt/trinity/lib/libqt-mt.so.3 #7 0xb75289d3 in DCOPClient::attachFailed (this=0x8091570, t0=...) at /dev/shm/kdelibs.build/dcop/dcopclient.moc:149 #8 0xb7531e5f in DCOPClient::attachInternal (this=0x8091570, registerAsAnonymous=false) at /dev/shm/kdelibs/dcop/dcopclient.cpp:782 #9 0xb753154b in DCOPClient::registerAs (this=0x8091570, appId=..., addPID=true) at /dev/shm/kdelibs/dcop/dcopclient.cpp:967 #10 0xb75f9afd in KApplication::dcopAutoRegistration (this=0xbfabf1fc) at /dev/shm/kdelibs/kdecore/kapplication.cpp:1099 #11 0xb760af1d in KApplication::init (this=0xbfabf1fc, GUIenabled=true) at /dev/shm/kdelibs/kdecore/kapplication.cpp:899 #12 0xb760fd1a in KApplication (this=0xbfabf1fc, allowStyles=true, GUIenabled=false) at /dev/shm/kdelibs/kdecore/kapplication.cpp:667 #13 0x080493ff in main (argc=1, argv=0xbfabf474) at /dev/shm/kdelibs/kdecore/kdetcompmgr.cpp:52 ============================
Anything obvious?
More observations, both using the nvidia proprietary drivers:
When I disable kdetcompmgr in startkde, I eliminate the first requirement to run killall kconf_update.
When I add the --no-kded parameter to the start_kdeinit_wrapper command in startkde, I eliminate the second killall.
Lastly, KPersonalizer seems to launch kdetcompmgr, even after I disable kdetcompmgr in startkde.
Darrell