Bug 161164 - Exchange connector crashes regularly
Exchange connector crashes regularly
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: evolution-connector (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Barnes
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-20 17:47 EDT by Jason Arnold
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-02 12:59:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jason Arnold 2005-06-20 17:47:32 EDT
Description of problem:
Using the exchange connector with a Windows 2003 Exchange server consistently
crashes Evolution after short periods (5 mins?) of use.  To restart evolution
after such a hang, I must kill all evolution processes (data-server,
exchange-storage) and run evolution again.


Version-Release number of selected component (if applicable):
evolution-2.2.2-5
evolution-connector-2.2.2-5

How reproducible:
Run evolution using exchange account.  Use for 5 mins, send an email, look up
users in GAL, use calendar.  Everything works (a bit slowly) for a while then hangs.

Steps to Reproduce:
1. see above :)
2.
3.
  
Actual results:
Crash

Expected results:
No crashes

Additional info:
I can't believe I'm the only person experiencing this problem, but I see no
other bug reports for similar issues.  My Ubuntu system right next to it doesn't
crash... but it doesn't do the GAL lookups, either (firewalled off from GAL server).
Comment 1 Dave Malcolm 2005-06-20 17:52:49 EDT
Thanks for this report.  Please can you install the evolution-debuginfo and
evolution-connector-debuginfo packages and attach a stack backtrace of the crash?

You can find more information on how to do this here:
http://fedora.linux.duke.edu/wiki/StackTraces

BTW, you can kill all of the various evolution processes by running:
"evolution --force-shutdown" at a terminal.
Comment 2 Jason Arnold 2005-06-20 19:46:36 EDT
will do.  Note that I've upgraded my evolution to 2.2.2-8 as it currently is in
either the updates or devel repository (I'm not clear on which it came from). 
It has helped the speed issues a bit (assuming I'm not imagining things), but I
still get the regular crashes.  I'll try to get you a backtrace.
Comment 3 Jason Arnold 2005-06-20 20:12:38 EDT
Here's a backtrace from where I noticed it hung.  I can't always tell when it
hangs cause the gui is still responsive, but if I kill Evo and restart it all of
a sudden I get new mail that it hasn't picked up for me before.

I had to ctrl-c into the gdb prompt, then I grabbed a trace:

(gdb) thread apply all bt

Thread 22 (Thread -1286390864 (LWP 27928)):
#0  0x00a0f402 in __kernel_vsyscall ()
#1  0x0024ccec in poll () from /lib/libc.so.6
#2  0x00977248 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#3  0x009776e3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#4  0x07b342f4 in e_book_set_default_source () from /usr/lib/libebook-1.2.so.3
#5  0x00a1fb80 in start_thread () from /lib/libpthread.so.0
#6  0x00256dee in clone () from /lib/libc.so.6

Thread 18 (Thread -1286390864 (LWP 27913)):
#0  0x00a0f402 in __kernel_vsyscall ()
#1  0x0024ccec in poll () from /lib/libc.so.6
#2  0x00977248 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#3  0x009776e3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#4  0x07b342f4 in e_book_set_default_source () from /usr/lib/libebook-1.2.so.3
#5  0x00a1fb80 in start_thread () from /lib/libpthread.so.0
#6  0x00256dee in clone () from /lib/libc.so.6

Thread 11 (Thread -1286390864 (LWP 27899)):
#0  0x00a0f402 in __kernel_vsyscall ()
#1  0x0024ccec in poll () from /lib/libc.so.6
#2  0x00977248 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#3  0x009776e3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#4  0x07b342f4 in e_book_set_default_source () from /usr/lib/libebook-1.2.so.3
#5  0x00a1fb80 in start_thread () from /lib/libpthread.so.0
#6  0x00256dee in clone () from /lib/libc.so.6

Thread 8 (Thread -1275081808 (LWP 27819)):
#0  0x00a0f402 in __kernel_vsyscall ()
#1  0x0024ccec in poll () from /lib/libc.so.6
#2  0x00977248 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#3  0x009776e3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#4  0x006833de in link_thread_io_context () from /usr/lib/libORBit-2.so.0
#5  0x0098fe9a in g_static_private_free () from /usr/lib/libglib-2.0.so.0
#6  0x00a1fb80 in start_thread () from /lib/libpthread.so.0
#7  0x00256dee in clone () from /lib/libc.so.6

Thread 7 (Thread -1264591952 (LWP 27815)):
#0  0x00a0f402 in __kernel_vsyscall ()
#1  0x00a217a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x07a633c7 in e_msgport_wait () from /usr/lib/libedataserver-1.2.so.4
#3  0x07a63abd in e_thread_busy () from /usr/lib/libedataserver-1.2.so.4
#4  0x00a1fb80 in start_thread () from /lib/libpthread.so.0
#5  0x00256dee in clone () from /lib/libc.so.6

---Type <return> to continue, or q <return> to quit---
Thread 6 (Thread -1254102096 (LWP 27813)):
#0  0x00a0f402 in __kernel_vsyscall ()
#1  0x00a217a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x07a633c7 in e_msgport_wait () from /usr/lib/libedataserver-1.2.so.4
#3  0x07a63abd in e_thread_busy () from /usr/lib/libedataserver-1.2.so.4
#4  0x00a1fb80 in start_thread () from /lib/libpthread.so.0
#5  0x00256dee in clone () from /lib/libc.so.6

Thread 5 (Thread -1243612240 (LWP 27788)):
#0  0x00a0f402 in __kernel_vsyscall ()
#1  0x00a217a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x07a633c7 in e_msgport_wait () from /usr/lib/libedataserver-1.2.so.4
#3  0x07a63abd in e_thread_busy () from /usr/lib/libedataserver-1.2.so.4
#4  0x00a1fb80 in start_thread () from /lib/libpthread.so.0
#5  0x00256dee in clone () from /lib/libc.so.6

Thread 4 (Thread -1231787088 (LWP 27787)):
#0  0x00a0f402 in __kernel_vsyscall ()
#1  0x00a2413b in __read_nocancel () from /lib/libpthread.so.0
#2  0x06826982 in do_read (marshal=0x9724bd0, buf=0x9894488 "\b", len=4)
    at /usr/include/bits/unistd.h:33
#3  0x06826afe in marshal_read (marshal=0x9724bd0,
    buf=0xb69463ef
"\212Hd\224\uffffHd\224\uffff\030d\224\uffff\uffffm\202\006\b7l\t\001", len=1)
---Type <return> to continue, or q <return> to quit---
    at camel-stub-marshal.c:117
#4  0x06826c33 in decode_uint32 (marshal=0x9724bd0, dest=0xb6946448)
    at camel-stub-marshal.c:149
#5  0x06826dd8 in camel_stub_marshal_decode_uint32 (marshal=0xfffffe00,
    dest=0xb6946448) at camel-stub-marshal.c:262
#6  0x06827569 in status_main (data=0x97392a0) at camel-stub.c:109
#7  0x00a1fb80 in start_thread () from /lib/libpthread.so.0
#8  0x00256dee in clone () from /lib/libc.so.6

Thread 3 (Thread -1221297232 (LWP 27786)):
#0  0x00a0f402 in __kernel_vsyscall ()
#1  0x00a2413b in __read_nocancel () from /lib/libpthread.so.0
#2  0x06826982 in do_read (marshal=0x9724bb8, buf=0x9780f30 "\uffff\006", len=4)
    at /usr/include/bits/unistd.h:33
#3  0x06826afe in marshal_read (marshal=0x9724bb8, buf=0xb734726f
"\006\uffffr4\uffff",
    len=1) at camel-stub-marshal.c:117
#4  0x06826c33 in decode_uint32 (marshal=0x9724bb8, dest=0xb73472f8)
    at camel-stub-marshal.c:149
#5  0x06826dd8 in camel_stub_marshal_decode_uint32 (marshal=0xfffffe00,
    dest=0xb73472f8) at camel-stub-marshal.c:262
#6  0x06827abc in stub_send_internal (stub=0x97392a0, ex=0xa114b50, oneway=0,
    command=4294966784, ap=0x30 <Address 0x30 out of bounds>)
    at camel-stub.c:308
---Type <return> to continue, or q <return> to quit---
#7  0x06827f90 in camel_stub_send (stub=0xfffffe00, ex=0x4, command=158863152)
    at camel-stub.c:493
#8  0x06824b32 in exchange_get_folder_info (store=0x971a598, top=0x0, flags=2,
    ex=0xa114b50) at camel-exchange-store.c:487
#9  0x07f3ff89 in camel_store_get_folder_info ()
   from /usr/lib/libcamel-provider-1.2.so.3
#10 0x08a13591 in get_folderinfo_get (mm=0xa114b38) at mail-ops.c:1065
#11 0x08a100e9 in mail_msg_received (e=0x9668360, msg=0xa114b38, data=0x0)
    at mail-mt.c:556
#12 0x07a63a51 in e_thread_busy () from /usr/lib/libedataserver-1.2.so.4
#13 0x00a1fb80 in start_thread () from /lib/libpthread.so.0
#14 0x00256dee in clone () from /lib/libc.so.6

Thread 2 (Thread -1210807376 (LWP 27785)):
#0  0x00a0f402 in __kernel_vsyscall ()
#1  0x00a217a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x07a633c7 in e_msgport_wait () from /usr/lib/libedataserver-1.2.so.4
#3  0x07ced95e in e_name_selector_model_peek_section ()
   from /usr/lib/libedataserverui-1.2.so.4
#4  0x07cee0f8 in e_passwords_get_password ()
   from /usr/lib/libedataserverui-1.2.so.4
#5  0x08a17916 in get_password (session=0x9680c98, service=0xb5e1b0d0,
    domain=0x8a41e85 "Mail",
---Type <return> to continue, or q <return> to quit---
    prompt=0xfffffffc <Address 0xfffffffc out of bounds>,
    item=0x91dfd0 "password", flags=4, ex=0xfffffffc) at mail-session.c:192
#6  0x07f3a440 in camel_session_get_password ()
   from /usr/lib/libcamel-provider-1.2.so.3
#7  0x0091d15a in camel_pop3_store_expunge ()
   from /usr/lib/evolution-data-server-1.2/camel-providers/libcamelpop3.so
#8  0x0091d7c1 in camel_pop3_store_expunge ()
   from /usr/lib/evolution-data-server-1.2/camel-providers/libcamelpop3.so
#9  0x07f395dd in camel_service_connect ()
   from /usr/lib/libcamel-provider-1.2.so.3
#10 0x07f3a256 in camel_session_get_service_connected ()
   from /usr/lib/libcamel-provider-1.2.so.3
#11 0x08a196da in mail_tool_get_inbox (
    url=0xfffffffc <Address 0xfffffffc out of bounds>, ex=0xa112868)
    at mail-tools.c:67
#12 0x08a11add in fetch_mail_fetch (mm=0xa112850) at mail-ops.c:295
#13 0x08a100e9 in mail_msg_received (e=0x9668360, msg=0xa112850, data=0x0)
    at mail-mt.c:556
#14 0x07a63a51 in e_thread_busy () from /usr/lib/libedataserver-1.2.so.4
#15 0x00a1fb80 in start_thread () from /lib/libpthread.so.0
#16 0x00256dee in clone () from /lib/libc.so.6

Thread 1 (Thread -1208183104 (LWP 27781)):
---Type <return> to continue, or q <return> to quit---
#0  0x00a0f402 in __kernel_vsyscall ()
#1  0x00a217a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x00668495 in giop_recv_buffer_get () from /usr/lib/libORBit-2.so.0
#3  0x0066ba55 in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
#4  0x0066bc26 in ORBit_small_invoke_stub_n () from /usr/lib/libORBit-2.so.0
#5  0x0067c4e9 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
#6  0x008803f5 in GNOME_Evolution_Component_sendAndReceive (_obj=0xfffffffc,
    ev=0xfffffffc) at Evolution-stubs.c:71
#7  0x0805f9bc in e_shell_send_receive (shell=0x9650868) at e-shell.c:1209
#8  0x0805c43c in command_send_receive (uih=0x9686f88, window=0xfffffffc,
    path=0x9f72748 "SendReceive") at e-shell-window-commands.c:637
#9  0x06e51047 in bonobo_socket_add_id () from /usr/lib/libbonoboui-2.so.0
#10 0x0011d285 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#11 0x075f580f in bonobo_closure_invoke_va_list ()
   from /usr/lib/libbonobo-2.so.0
#12 0x075f5a47 in bonobo_closure_invoke () from /usr/lib/libbonobo-2.so.0
#13 0xbfaea180 in ?? ()
#14 0xbfaea1dc in ?? ()
#15 0x00134a86 in g_type_value_table_peek () from /usr/lib/libgobject-2.0.so.0
Previous frame inner to this frame (corrupt stack?)
Comment 4 Dave Malcolm 2005-06-22 11:11:27 EDT
Thanks.

It looks like the main UI thread is trying to Send/Receive mail (perhaps due to
evolution being configured to do this automatically?), and is waiting for a
response from an out-of-process component which I assume is
evolution-exchange-storage.

(The POP provider running in thread 2 is trying to do an "expunge" operation,
but needs a password before it can proceed, and is waiting for the main UI
thread to deal with that).

Please can you try attaching gdb to the evolution-exchange-storage process when
evolution hangs and get a backtrace of what it's doing at the time?
Comment 5 Jason Arnold 2005-06-28 20:27:50 EDT
1) How do I attach gdb to the evolution-exchange-storage process?  It was easy
to do so with the evolution process itself since I just invoked it as gdb
evolution... but I'm not sure how to invoke the exchange-storage process.

Also note that my problems have magically disappeared on their own.  The
exchange process seems to be working more or less flawlessly now... I'm
mystified as I've not made any system changes (perhaps our exchange server was
hiccuping at the time?).

So in short my system is now fine... I'm happy to help track down the bug, but I
can't reproduce it any more *sheepish grin*.  Please let me know if there's any
more info I can get you that'd be useful.
Comment 6 Dave Malcolm 2005-06-29 11:49:01 EDT
Thanks for the feedback; good to hear that it's working for you now.

My theory is that for some reason, the evolution-exchange-storage process hung,
and evolution was waiting to talking to it and thus hung itself.

I don't know if we're going to see this problem again, so for now I'm going to
resolve this bug, marking it as WORKSFORME.  Feel free to reopen this bug if the
symptoms recur.

For future reference, if you're attaching to the process, simply locate the PID
of the process, either by running gnome-system-monitor and browsing for it, or
by running:
ps ax | grep exchange

Then type: gdb attach the-PID-of-the-process
and type: "cont" to continue once gdb has started.

Hope this helps
Comment 7 Jason Arnold 2005-06-29 12:45:17 EDT
Ok it worked for half a week just fine, now it's doing it again.  Here's the
attach to evolution-exchange-storage; the following took place over about 15
minutes.

[New Thread -1224737872 (LWP 5630)]
[New Thread -1210897488 (LWP 5631)]
[Thread -1224737872 (LWP 5630) exited]
[Thread -1210897488 (LWP 5631) exited]
[New Thread -1210897488 (LWP 5632)]
[New Thread -1224737872 (LWP 5634)]
[Thread -1224737872 (LWP 5634) exited]
[Thread -1210897488 (LWP 5632) exited]
[New Thread -1210897488 (LWP 5636)]
[New Thread -1224737872 (LWP 5648)]
[New Thread -1235227728 (LWP 5649)]
[Thread -1210897488 (LWP 5636) exited]
[Thread -1224737872 (LWP 5648) exited]
[New Thread -1224737872 (LWP 5660)]
[Thread -1224737872 (LWP 5660) exited]
[New Thread -1224737872 (LWP 5662)]
[Thread -1224737872 (LWP 5662) exited]
[New Thread -1224737872 (LWP 5666)]
[Thread -1224737872 (LWP 5666) exited]
[Thread -1235227728 (LWP 5649) exited]
[New Thread -1235227728 (LWP 5672)]
[Thread -1235227728 (LWP 5672) exited]
[New Thread -1235227728 (LWP 5702)]
[Thread -1235227728 (LWP 5702) exited]
Comment 8 Bojan Smojver 2005-06-30 20:20:09 EDT
Just a "me too" with the latest Evo builds:

evolution-webcal-2.2.1-1.fc4
evolution-2.2.3-1.fc4
evolution-connector-2.2.3-1.fc4
evolution-data-server-1.2.3-1.fc4
Comment 10 Matthew Barnes 2006-12-31 12:21:51 EST
Is this problem still observed in Fedora Core 6?
Comment 11 Matěj Cepl 2007-08-31 11:23:29 EDT
The distribution against which this bug was reported is no longer supported,
could you please reproduce this with the updated version of the currently
supported distribution (Fedora Core 6, or Fedora 7, or Rawhide)? If this issue
turns out to still be reproducible, please let us know in this bug report.  If
after a month's time we have not heard back from you, we will have to close this
bug as INSUFFICIENT_DATA.

Setting status to NEEDINFO, and awaiting information from the reporter.

Thanks in advance.
Comment 12 Matthew Barnes 2007-10-02 12:59:49 EDT
Closing as INSUFFICIENT_DATA.

Note You need to log in before you can comment on or make changes to this bug.