28 Nov
2011
28 Nov
'11
7:58 a.m.
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