|Summary:||Evolution fails to start in XFCE4 desktop environment|
|Product:||[Fedora] Fedora||Reporter:||Andrew Farris <lordmorgul>|
|Component:||evolution||Assignee:||Dave Malcolm <dmalcolm>|
|Status:||CLOSED WORKSFORME||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-10-22 04:28:07 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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): evolution-2.0.0-2 How reproducible: Always 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 `OAFIID:GNOME_Evolution_Addressbook_Component:2.0' 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 --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
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
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?