Bug 135977

Do you have iceauth installed and in your patH?

yes

Also, when i killed dcopserver, I got:
ICE default IO error handler doing an exit(), pid = 21662, errno = 0                                     
ICE default IO error handler doing an exit(), pid = 21660, errno = 95
DCOPClient::attachInternal. Attach failed Could not open network socket
DCOPClient::attachInternal. Attach failed Could not open network socket
WARNING: DCOP communication problem!
kdeinit: Communication error with launcher. Exiting!

Does it work with a newly created user? When did the problem start? Did it ever work on your installation?

Fails with a newly-created user. Always worked fine until the problem started. 

Problem started last night. I noticed it after I restarted X after I upgraded to kdelibs-3.5.5-r3 from kdelibs-3.5.5 (that would be release four of the 3.5.5 gentoo ebuild). I've since downgraded again, and the problem remains. I no longer think it's likely that that caused the problem. I think it was something I did that wouldn't affect dcop while it was running, but would only affect startup.

One reason I jumped right to permissions (besides the obvious root works/user doesn't) is that i ran wireshark under sudo (not usually recommended to run gui apps with sudo) and I was worried it messed with my permissions somehow. I've straced it running while I performed the same operations I did before, and then I checked what it wrote to- nothing that would mess anything up.

i've also straced kdeinit, dcopserver, and kmail, looking for access denied- haven't found anything suspicious.

Created attachment 18197 [details]
strace of ktorrent starting up

(With all kde programs dead)
strace -f -o ktorrent.log ktorrent

Created attachment 18202 [details]
New strace 

Ok, I've done straces of ktorrent starting up as root and failing to as the
user (mike). I ran each after making sure dcopserver, kdeinit, and all other
kde-related processes were dead.

I compared them with vimdiff. To facilitate comparison, I have done the
following transformations:

I converted pids to their process names (globally). I missed a few, and they
are named dunno_a through dunno_f, but the names are consistent.

:%s/\/home\/mike/$HOME/g
:%s/mike/username/g
:%s/0x[0-9a-f]\{12\}/0xdeadbeefbeef/g
:%s/0x[0-9a-f]\{6\}\([^0-9a-f]\|$\)/0xbeefdead/g

I am aware that the last pattern is buggy (it will eat the next character after
the pointer). I don't think that makes much difference in this case, since it
will eat a , or )

The root version is too long for bugzilla's little mind, so here's a link:
http://www.fluffypenguin.org/gentoo/ktorrent-new-root.log

This one has the same addendum as the previous one, except /home/mike becomes /root and mike becomes root. Also, I have trimmed this one to 15,000 lines.

One more data point: kded will sometimes go to 100% cpu and stay there until i kill it, like it's spinning waiting for something.

Sounds like a configuration problem, rather than a KDE bug - you should probably try asking in some of your distro's support forums

You're right. Considering that root works and user doesn't, it's probably a configuration problem. I'm just trying to ask experts about a problem that's stumped me for two days now. There must be some way of getting the apps to tell me why they can't connect. This is silly.

To check the permissions, I ran find / on this system and a working one. I then took the intersection of those sets. I then stat'd every file in that list on both machines, and compared the permissions. There were no significant differences. 

I've placed a bounty on this bug. Go to http://bugs.gentoo.org/show_bug.cgi?id=152161 for more information.

Problem solved.