Bug 133983

Thanks for thr report.  Please can you do:
ps ax | grep bonobo

and post the results (if any) here?

Also, please can you attach to the evolution process in gdb, and post
the result of "thread apply all backtrace" here too
(see http://fedora.linux.duke.edu/wiki/StackTraces for more info)

Ah, yes sorry the bt wasn't here in the first place.  Here we are,
something useful I hope.

 -> ps ax | grep evolution
17953 pts/0    S      0:00 evolution
17959 ?        Sl     0:00 /usr/libexec/evolution-data-server-1.0
--oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck
--oaf-ior-fd=30
17967 ?        S      0:00
/usr/libexec/evolution/2.0/evolution-exchange-storage
--oaf-activate-iid=OAFIID:GNOME_Evolution_Exchange_Component_Factory:2.0
--oaf-ior-fd=32
17971 pts/0    R+     0:00 grep evolution

 -> ps ax | grep bonobo
30494 ?        Ss     0:00 /usr/libexec/bonobo-activation-server
--ac-activate --ior-output-fd=18
17982 pts/0    R+     0:00 grep bonobo


Thread 1 (Thread -151144704 (LWP 17953)):
#0  0x0027c782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00a7f33d in poll () from /lib/tls/libc.so.6
#2  0x00c4cf13 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0
#3  0x00c4d468 in g_main_context_iteration () from
/usr/lib/libglib-2.0.so.0
#4  0x04584a41 in link_main_iteration () from /usr/lib/libORBit-2.so.0
#5  0x0456936f in giop_recv_buffer_get () from /usr/lib/libORBit-2.so.0
#6  0x0456cbb8 in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
#7  0x0456cda9 in ORBit_small_invoke_stub_n () from
/usr/lib/libORBit-2.so.0
#8  0x0457f3a7 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
#9  0x04776226 in Bonobo_ActivationContext_activateMatchingFull ()
from /usr/lib/libbonobo-activation.so.4
#10 0x04778020 in bonobo_activation_activate () from
/usr/lib/libbonobo-activation.so.4
#11 0x04778294 in bonobo_activation_activate_from_id () from
/usr/lib/libbonobo-activation.so.4
#12 0x08052b47 in query_components (registry=0x95ec308) at
e-component-registry.c:194
#13 0x0805329d in e_component_registry_peek_list (registry=0x95ec308)
at e-component-registry.c:299
#14 0x080621fc in e_shell_construct (shell=0x956cb20, iid=0x8069128
"OAFIID:GNOME_Evolution_Shell:2.0",
    startup_line_mode=E_SHELL_STARTUP_LINE_MODE_CONFIG) at e-shell.c:638
#15 0x08062326 in e_shell_new (startup_line_mode=4294967292,
construct_result_return=0xfef9aadc) at e-shell.c:690
#16 0x080633f2 in idle_cb (data=0x0) at main.c:344
#17 0x00c4e848 in g_child_watch_add () from /usr/lib/libglib-2.0.so.0
#18 0x00c4b4fb in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#19 0x00c4cf82 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0
#20 0x00c4d22f in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#21 0x04669dd5 in bonobo_main () from /usr/lib/libbonobo-2.so.0
#22 0x08063a69 in main (argc=-1, argv=0xfef9afc4) at main.c:585
#0  0x0027c782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

OK - it looks like Evolution's GUI thread has blocked, early in the
startup sequence; it's waiting for a response from the
bonobo-activation-server process.   The bonobo-activation-server
process looks like it's getting started by Evolution, can you attach
to it using gdb and give a backtrace of that as well, please?  

My current guess is that an environment variable that's set up when
running GNOME doesn't get set by the XFCE environment, and the
bonobo-activation-server is confused.  It may fix things if you run
"evolution --force-shutdown", kill the bonobo-activation-server
process and any other processes associated with evolution, and set
GNOME2_PATH=/ in the environment in which you launch evolution, though
that's a guess at this stage.

Bingo, after "export GNOME2_PATH=/" evolution starts and seems to
function correctly.

Unfortunately, I tried the fix before I got the backtrace (which
seemed logical at the time), and I cannot reproduce the bug anymore. 
I have tried to 'unset' the var, have fully rebooted the box, have rm
-Rf'd /tmp from runlevel 1 before logging in with gdm -- and nothing
seems to break it again.  The var is no longer set in my shell, and
yet evolution will start up happily when I have rebooted and logged
back in.

Suggestions?  I'm assuming some black magic is at work here and
bonobo-activation-server is remembering things.  The interesting
difference here is that it did not work before when I had run gnome
and then switched to xfce without a reboot.  So you fixed my problem
but right now I can't help you fix the problem until I can revert
something to the pre-export state it was in. :)

Awesome!  I'm glad it's working for you now, though it'd be good to
know  why :-)

Looking at the source of bonobo-activation-server, in addition to the
env var GNOME2_PATH, it also uses BONOBO_ACTIVATION_PATH; it also
loads configuration information from /etc/oaf/oaf-conf.xml

So do you think either of these have got set?

oaf was not installed at the time.. could this have been involved? 
Nothing I have installed depends directly on oaf.

BONOBO_ACTIVATION_PATH is also not set but I do not know if it is
being set at some point locally and not exported.  Still no luck
recreating this, I may be able to dig deeper (uninstall xfce and clean
things up) in a few days.  A new user account I tried also started
evolution immediately (without the var set by me or otherwise), the
change has occurred globally to the system.

I presume that getting the GNOME2_PATH var set in xfce startup scripts
would be a step in the right direction, but the hang in
bonobo-activation-server I will try to recreate if possible.
-- does this bug need relocated? Its not really evolution afterall.

You deleted all the /tmp files, didn't you...

BTW, were you logged in as root the first time you tried setting the
environment variable?

Yes /tmp was rm -rf'd in runlevel 1.  The new user was created in
runlevel 3 so I could check the login, and then back to runlevel 5
where new user was able to start evolution immediately.

No, the only time I exported the variable GNOME2_PATH was as normal
user.  It was done only once too, before /tmp was cleaned.

Follow up here, this problem was not present when I fresh installed from FC3t3
(and hasn't resurfaced in rawhide from there).  I do not see any changelog
entries anywhere that suggest this was specifically fixed, however.

Neither of the vars GNOME2_PATH or BONOBO_ACTIVATION_PATH are set while the
environment is active.  Neither of them are present in the script
/usr/bin/startxfce4 or the scripts it references (/etc/xfce4/xinitrc
/etc/xfce4/xfce4rc, or the equivalent in my home).

Thanks.  So, am I right in thinking that it's working for you, that we
can't reproduce this, and we don't know exactly why the problem went away?

(I'm inclined at this stage to resolve this as WORKSFORME, and reopen
it if problems recur)

That is correct.

Hi
I am having a similar problem but not only with evolution, also with
gnome-terminal. I've tried your solution and that didn't work. Are
there any sugestions? May I help in anything?