GNOME Bugzilla – Bug 92151
Panel fails to load applets on startup, citing Unknown CORBA exception
Last modified: 2009-08-15 18:40:50 UTC
Description of Problem: After logging in, gnome-panel should start along with the applets. However, 4 out of 5 times, the panel fails to load the applets, with the error message (not exact): "There was a problem loading OAFID:.... Unknown CORBA exception... CORBA/INV_OBJREF". Thereafter, even when I try to add applets back via the panel's popup menu, the same error comes up. Sometimes it takes several logins before I can start adding applets back. Needless to say this is extremely annoying. Steps to reproduce the problem: Sorry, I don't know the exact conditions which triggers this bug. As I said, it happens 4 out of 5 times. Actual Results: Panel should successfully loads the applets. Expected Results: Panel fails to load the applets. How often does this happen? 80% of the time. Additional Information: Running Debian sid, using GNOME2 packages in experimental.
If oafd is running when I logout, the chances of triggering this bug is very high.
Sounds like some kind of race condition. Without either more logging data or better instructions on how to reproduce, it's going to be very hard to reproduce. How are you logging in? GDM? What versions of oaf, gdm, panel, etc?
Created attachment 10888 [details] My ~/.Xsession
Sorry, I know it's very hard to debug without instructions on how to reproduce it, but I'm at a loss at how to reproduce it either. I'm using what was current in Debian sid/experimental a week ago, namely: gdm 2.2.5.5-2 oaf 0.6.10-2 liborbit0 0.5.16-1 bonobo-activation4 1.0.3-2 liborbit2 2.4.1-1 gnome-panel2 2.0.7-1 gnome-applets2 2.0.2-1 gnome-session2 2.0.6-1 libbonobo2-0 2.0.0-1 libbonoboui2-0 2.0.1-2 Any other dependencies do you need? The previous attachment my ~/.Xsession script that I use to login with. "unihan-client" is a proprietary Chinese input method server, and it uses gconf2 (in case that can be a problem). When the panel fails to load applets, it takes one or more "bonobo-slay" before applets can be added to the panel again. The panel does not need to be restarted for this.
I've recompiled gnome-panel2, libbonobo2-0 and libbonobo-activation4 with -g. Using gdb, I traced down to which bonobo function failed. Here's a backtrace: ----------
+ Trace 27118
Bonobo_ActivationContext_activate_from_id() would return a NULL. Any ideas?
Is there by any chance something on your system that is deleting files from /tmp. When this problem occurs is there a bonobo-activation-server running but no /tmp/orbit-$(username)/bonobo-activation-server-ior ?
OK, I have gnome-panel2 currently running as I type this. ---------- spacehunt@foobar:/tmp/orbit-spacehunt$ ior-decode-2 `cat bonobo-activation-server-ior ` Object ID: IDL:Bonobo/ActivationContext:1.0 IOP_TAG_GENERIC_IOP: GIOP 1.2[UNIX] foobar:/tmp/orbit-spacehunt/linc-4665-0-7ca7d732abc64 IOP_TAG_ORBIT_SPECIFIC: usock /tmp/orbit-spacehunt/linc-4665-0-7ca7d732abc64 IPv6 port 0 object_key (28) '0000000056d6d4d0bd8ee8a8c02b282828282828030000004a58742c' IOP_TAG_MULTIPLE_COMPONENTS: IOP_TAG_COMPLETE_OBJECT_KEY: object_key (28) '0000000056d6d4d0bd8ee8a8c02b282828282828030000004a58742c' Unknown component 0x1 spacehunt@foobar:/tmp/orbit-spacehunt$ cat linc-4665-0-7ca7d732abc64 cat: linc-4665-0-7ca7d732abc64: No such device or address spacehunt@foobar:/tmp/orbit-spacehunt$ ---------- "No such device or address"? Is this supposed to happen? I have IPv4 and IPv6 disabled in /etc/orbitrc (this is Debian's default).
That looks fine - what that means is that bonobo-activation-server has shut down because it is idle but the important thing to find out (I think) is if bonobo-activation-server is running on login does /tmp/orbit-$(user)/bonobo-activation-server-ior hold a valid ior of it ?
i have been experiencing the same problem. i'm not sure how to check that /tmp/orbit-$(user)/bonobo-activation-server-ior is a VALID ior... is there a list of valid ones stored somewhere that i can check against next time i have the problem? also, the only reliable way to fix the problem so far has been to log out, kill all of ${user}'s processes (gconfd, esd, sometimes oafd), and rm -rf /tmp/orbit-${user} before logging in again. Should there be a way to fix this without having to log out/in? one more problem that seems to be related (i.e., when it happens, this problem tends to happen), is that i get an error message on session startup saying something like "the gnome-settings-daemon could not be started because it was restarted too many times"... i often get this after a clean boot, too...
I also have the same problem. I have gnome 2.0 on Red Hat 8.0 and recently upgraded to red hat 8.0.93 and the problem still exists. I tried to reboot as root and rm the /tmp/orbit-username folder but the problem still exists.
This is related to IP information... I've the problem as well when changing IP address. You can solve it by changing the /etc/hosts
Should this still be NEEDINFO?
Closing. No new information on this in ages.