Bug 133983

Summary: Evolution fails to start in XFCE4 desktop environment
Product: [Fedora] Fedora Reporter: Andrew Farris <lordmorgul>
Component: evolutionAssignee: Dave Malcolm <dmalcolm>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: lordmorgul
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-22 04:28:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Andrew Farris 2004-09-28 20:23:57 UTC
Description of problem:
Evolution will not load and display itself in XFCE4 whereas it works
correctly in Gnome on the same system.  XFCE packages are from Rawhide
only but were installed by manual selection through yum.. perhaps I
have missed required packages for evolution to interact correctly when
Gnome is not running.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Login to XFCE session
2. Launch 'evolution' in terminal

Actual results:
Evolution runs as a process but no window is displayed, the process
sleeps almost immediately.  The only output from evolution is:
asked to activate component_id

Expected results:
Evolution window displayed.

XFCE4 packages:
xfce-mcs-manager                    i386   4.0.6-2                 
xfce-mcs-manager-debuginfo          i386   4.0.6-2                 
xfce-mcs-manager-devel              i386   4.0.6-2                 
xfce-mcs-plugins                    i386   4.0.6-2                 
xfce-mcs-plugins-debuginfo          i386   4.0.6-2                 
xfce-utils                          i386   4.0.6-1                 
xfce-utils-debuginfo                i386   4.0.6-1                 
xfce4-iconbox                       i386   4.0.6-2                 
xfce4-iconbox-debuginfo             i386   4.0.6-2                 
xfce4-panel                         i386   4.0.6-1                 
xfce4-panel-debuginfo               i386   4.0.6-1                 
xfce4-systray                       i386   4.0.6-1                 
xfce4-systray-debuginfo             i386   4.0.6-1                 
xfdesktop                           i386   4.0.6-2                 
xfdesktop-debuginfo                 i386   4.0.6-2                 
xffm                                i386   4.0.6-1                 
xffm-debuginfo                      i386   4.0.6-1                 
xffm-icons                          noarch 1:4.0.6-2               
xfprint                             i386   4.0.6-2                 
xfprint-debuginfo                   i386   4.0.6-2                 
xfwm4                               i386   4.0.6-1                 
xfwm4-debuginfo                     i386   4.0.6-1                 
xfwm4-themes                        noarch 4.0.6-2

Comment 1 Dave Malcolm 2004-09-28 20:40:55 UTC
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)

Comment 2 Andrew Farris 2004-09-29 11:10:27 UTC
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
17967 ?        S      0:00
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
#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
#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
#11 0x04778294 in bonobo_activation_activate_from_id () from
#12 0x08052b47 in query_components (registry=0x95ec308) at
#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
    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
#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

Comment 3 Dave Malcolm 2004-09-29 14:23:14 UTC
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.

Comment 4 Andrew Farris 2004-09-30 00:36:38 UTC
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. :)

Comment 5 Dave Malcolm 2004-09-30 14:29:11 UTC
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?

Comment 6 Andrew Farris 2004-10-01 07:01:31 UTC
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.

Comment 7 Dave Malcolm 2004-10-01 18:47:20 UTC
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?

Comment 8 Andrew Farris 2004-10-01 23:22:40 UTC
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.

Comment 9 Andrew Farris 2004-10-21 05:05:58 UTC
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).

Comment 10 Dave Malcolm 2004-10-21 18:23:35 UTC
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)

Comment 11 Andrew Farris 2004-10-22 04:28:07 UTC
That is correct.

Comment 12 Carlos 2005-02-17 06:50:53 UTC
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?