If you point me at the debuginfo rpm I will run gdb.

Seems to work properly if I use strace.

Killing evolution-wombat and/or evolution-alarm-notify seems to be required
after killing the hung evolution.

I found killing evolution-wombat and/or evolution-alarm-notify while it is hung
causes it to then exit properly. I am thinking evolution-wombat.

Although my Evolution (1.4.4-3) client does not hang, it does leave wombat
droppings whenever I exit.

Confirming...

Confirmed.. 

the evolution client (1.4.4-3) does get stuck almost every time provided that
one makes an operation on messages (preferably delete and expunge). Just opening
and closing evolution does not seem to make it hang. I realize this is a bit
different than what the original reporter stated. :)

A 2 cent backtrace in case it helps (doubtful?)

....
Loaded symbols for /lib/libnss_dns.so.2
0x0031244e in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) bt
#0  0x0031244e in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x0059f963 in poll () from /lib/tls/libc.so.6
#2  0x008afe16 in g_main_loop_get_context () from /usr/lib/libglib-2.0.so.0
#3  0x008af246 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#4  0x008af4fc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#5  0x061d7939 in link_main_iteration () from /usr/lib/libORBit-2.so.0
#6  0x061ba54c in giop_recv_buffer_get () from /usr/lib/libORBit-2.so.0
#7  0x061be25c in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
#8  0x061be150 in ORBit_small_invoke_stub_n () from /usr/lib/libORBit-2.so.0
#9  0x061d1712 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
#10 0x00118fb1 in Bonobo_Unknown_unref ()
   from /usr/lib/libbonobo-activation.so.4
#11 0x00d7ea06 in cal_mode_enum_get_type ()
   from /usr/lib/evolution/1.4/libcal-client.so.0
#12 0x00d7eb5e in cal_mode_enum_get_type ()
   from /usr/lib/evolution/1.4/libcal-client.so.0
#13 0x0029dc3d in g_object_class_list_properties ()
   from /usr/lib/libgobject-2.0.so.0
#14 0x046fddd6 in e_summary_tasks_free ()
   from /usr/lib/evolution/1.4/components/libevolution-executive-summary.so
#15 0x046f1d6a in e_cell_tri_new ()
   from /usr/lib/evolution/1.4/components/libevolution-executive-summary.so
#16 0x002ae051 in g_cclosure_marshal_VOID__VOID ()
   from /usr/lib/libgobject-2.0.so.0
#17 0x0029c007 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
#18 0x0029bcb0 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#19 0x002ad84d in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#20 0x002acc36 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
(gdb)

Meanwhile evolution-wombat is somewhere waiting for a mutex:

(gdb)
#0  0x00ae144e in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00ec030b in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
#2  0x089392e0 in ?? ()
#3  0x061ee028 in ?? () from /usr/lib/libORBit-2.so.0
#4  0x000004d3 in ?? ()
#5  0x00ebd3b9 in pthread_mutex_lock () from /lib/tls/libpthread.so.0
#6  0x061ceaf0 in ORBit_recv_buffer_return_sys_exception () from
/usr/lib/libORBit-2.so.0
#7  0x061d2b11 in ORBit_handle_request () from /usr/lib/libORBit-2.so.0
#8  0x061bb1bd in giop_connection_handle_input () from /usr/lib/libORBit-2.so.0
#9  0x061d9b6f in link_connection_set_max_buffer () from /usr/lib/libORBit-2.so.0
#10 0x061dba60 in link_servers_move_io_T () from /usr/lib/libORBit-2.so.0
#11 0x008adfad in unblock_source () from /usr/lib/libglib-2.0.so.0
#12 0x008aefa8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#13 0x008af2bf in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#14 0x008af4fc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#15 0x061d7939 in link_main_iteration () from /usr/lib/libORBit-2.so.0
#16 0x061ba54c in giop_recv_buffer_get () from /usr/lib/libORBit-2.so.0
#17 0x061be25c in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
#18 0x061be150 in ORBit_small_invoke_stub_n () from /usr/lib/libORBit-2.so.0
#19 0x061d1712 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
#20 0x001b7fb1 in Bonobo_Unknown_unref () from /usr/lib/libbonobo-activation.so.4
#21 0x00e63e04 in bonobo_object_release_unref () from /usr/lib/libbonobo-2.so.0
#22 0x080def9f in cal_new ()
#23 0x00930c3d in g_object_class_list_properties () from
/usr/lib/libgobject-2.0.so.0
#24 0x00e63977 in bonobo_url_lookup () from /usr/lib/libbonobo-2.so.0
#25 0x061cdc65 in ORBit_POA_setup_root () from /usr/lib/libORBit-2.so.0
#26 0x061cedcf in ORBit_POAObject_post_invoke () from /usr/lib/libORBit-2.so.0
#27 0x061ce188 in ORBit_recv_buffer_return_sys_exception () from
/usr/lib/libORBit-2.so.0
#28 0x061ce5a2 in ORBit_recv_buffer_return_sys_exception () from
/usr/lib/libORBit-2.so.0
#29 0x061ce94c in ORBit_recv_buffer_return_sys_exception () from
/usr/lib/libORBit-2.so.0
#30 0x061d2b11 in ORBit_handle_request () from /usr/lib/libORBit-2.so.0
#31 0x061bb1bd in giop_connection_handle_input () from /usr/lib/libORBit-2.so.0
#32 0x061d9b6f in link_connection_set_max_buffer () from /usr/lib/libORBit-2.so.0
#33 0x061dba60 in link_servers_move_io_T () from /usr/lib/libORBit-2.so.0
#34 0x008adfad in unblock_source () from /usr/lib/libglib-2.0.so.0
#35 0x008aefa8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#36 0x008af2bf in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#37 0x008af99f in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#38 0x00e5f088 in bonobo_main () from /usr/lib/libbonobo-2.so.0
#39 0x0805dffc in main ()
(gdb)

And the backtrace of evolution-alarm-notify ..

(gdb) bt
#0  0x00c1044e in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00ce491c in poll () from /lib/tls/libc.so.6
#2  0x008afe16 in g_main_loop_get_context () from /usr/lib/libglib-2.0.so.0
#3  0x008af246 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#4  0x008af99f in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#5  0x003f8088 in bonobo_main () from /usr/lib/libbonobo-2.so.0
#6  0x08058279 in main ()
(gdb)

All packages are the from an up to date rawhide copy (20030822)

I later found it wasn't everytime, but just seemed like it at first. I think you
likely nailed it down.

wombat remains running so that any alarm notifications you have can still pop up
at the appropriate time even after evolution quits (this is no different from
earlier versions of evolution).

I'm not seeing hangs here, but I'll look for them.  You might want to make sure
you have the rest of the gnome 2.4 stack upgraded (since there are some weird
interdependencies there I think that aren't necessarily all expressed in the
packages :/)

Bug seems to be fixed in 1.4.4-5. I opened Evoltuion, expunged some directories,
and closed just fine.

I'm still having this issue with a system updated to latest rawhide from 200030906.

I do not use an LDAP server from Evolution on a second system and it closes fine
there.

I don't have it on exit. Now it happens in the middle of doing things. The cause
is still evolution-wombat, and from what I can tell it is a bug in Orbit2-2.8.0.

I just saw it hang on exit again, and killing evolution-wombat unhung it.

From everything I have heard and seen I suspect it happens like this:

1. Evolution depends on evolution-wombat and sits waiting on it.
2. evolution-wombat depends on ORBit 2.8.0 and sits waiting on it.
3. ORBit is either incompatiable with glibc-2.3.2-27.9 or glibc has a bug in it


Killing evolution-wombat when Evolution always works. Evolution unhangs and
restarts evolution-wombat. As far as I know Red Hat 9 users don't have this
problem, and I have heard the problem relates to ORBit 2.8.0. Using "export
LD_ASSUME_KERNEL=2.2.5" seems to be a workaround. I have been using it since
yesterday, and have not been able to reproduce the problem.

Just to add a bit more color to it: It also happens here, but I can work around
it by switching to some other component (Calendar, Contacts, Tasks) before exiting.

*** Bug 103916 has been marked as a duplicate of this bug. ***

Problem still there with evolution-1.4.5-2

I just got Fedora core beta my machine does the same thing

I have tried ORBit2 2.8.1 and 2.7.5, neither helped. I would try going back
farther, but Evolution 1.4.5 requires at least 2.7.5. I have also found that
export LD_ASSUME_KERNEL=2.4.19 at best makes the bug a little rarer, but doesn't
completely workaround it. I am going to try to dig into this more since I don't
want to see a very broken version of Evolution in the next release.

E-mail sent to michael who works on ORBit2:


  I figured out a way to stop evolution from hanging. I recompiled evolution and
ORBit2 with debugging and tracked it toORBit_POA_handle_request() in
ORBit2-2.8.1/src/orb/poa/poa.c.  It dies at the code below, or at least this is
what is at line 1440 that gdb mentioned. gdb suggested a mutex lock that wasn't
being unlocked. So I compared 2.8.1, 2.8.0, 2.7.5, and 2.6.2. I found the main
difference was POA_LOCK (poa); on line 1421 of poa.c. I commented this line out,
recompiled, and Evolution doesn't hang.

              default:
                        g_assert_not_reached ();
                        break;

  I am somewhat doubtful if this is the proper fix, but it should at least point
you in the right direction. Another hint from gdb was thecurrent frame and
previous frame were the same, it suggested stack corruption.

The fix for this is in ORBit2 CVS. I have compiled the CVS code, packaged it,
and given it a try. It works better than my workaround.