> 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