Bug 189798 - Moving appointment between Exchange and Personal hangs evolution
Moving appointment between Exchange and Personal hangs evolution
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: evolution-connector (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Barnes
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-24 15:04 EDT by Russell Harrison
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-02 13:38:14 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 Russell Harrison 2006-04-24 15:04:02 EDT
+++ This bug was initially created as a clone of Bug #171602 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923
Epiphany/1.6.5

Description of problem:
If I move an appointment between my Exchange calendar and my Personal (local)
calendar, evolution hangs.
The hang happens in both directions.

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


How reproducible:
Always

Steps to Reproduce:
x

Additional info:

-- Additional comment from dmalcolm@redhat.com on 2005-10-24 13:51 EST --
Thanks for this report.

Please can you do the following to help isolate what's going wrong:
1. Install the debuginfo packages for evolution, evolution-data-server and
evolution-connector 
2. Restart Evolution, and reproduce the hang.
3. Use "ps ax | grep evo" in a terminal to determine the ID of the evolution process
4. Type "gdb attach" followed by the id of the evolution process.
5. In gdb, type "t a a bt" to get a backtrace of all threads within the
evolution process, and attach the result to this bug.
6. Quit gdb (detaching from the process)
7. Repeat steps 3-6 for the evolution-data-server process (or, if it doesn't
exist, that's useful information as well).
8. Repeat step 7 for the evolution-exchange-storage process
Thanks

-- Additional comment from redhat@nodata.co.uk on 2005-10-24 14:06 EST --
Please can I have a evolution-connector-debuginfo package?

-- Additional comment from dmalcolm@redhat.com on 2005-10-24 14:16 EST --
Try here:
http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/debug/evolution-connector-debuginfo-2.2.2-5.i386.rpm

assuming that that corresponds to your evolution-coneector package - what does
rpm -q evolution evolution-data-server evolution-connector
say?

-- Additional comment from redhat@nodata.co.uk on 2005-10-24 14:39 EST --
That's odd. yum doesn't know about it.

$ yum list evolution-connector-debuginfo*
Setting up repositories
Reading repository metadata in from local files
$ yum list evolution-debuginfo*
Setting up repositories
Reading repository metadata in from local files
Installed Packages
evolution-debuginfo.i386                 2.2.3-2.fc4            installed

$ rpm -q evolution evolution-data-server evolution-connector
evolution-2.2.3-2.fc4
evolution-data-server-1.2.3-3.fc4
evolution-connector-2.2.2-5

-- Additional comment from redhat@nodata.co.uk on 2005-10-24 15:03 EST --
Created an attachment (id=120317)
requested stack traces


-- Additional comment from dmalcolm@redhat.com on 2005-10-24 15:23 EST --
Thanks for the stack traces.

The evolution process' main UI thread is blocked, waiting for a fork to complete
(although the stack trace for that process looks bogus).  One of the other
threads (thread 5) is blocking: it's the camel backend for the exchange email;
it's partly through a read of enail data from the evolution-exchange-storage
process.

Both the e-d-s and evolution-exchange-storage processes are idling, waiting for
requests.

Perhaps one or both of the evolution-exchange-storage or e-d-s processes are
dying midway through this.  Do the process numbers change?  Shut everything down
by quitting evolution, then running "evolution --force-shutdown".  Then start
evolution, and try a "ps ax | grep evo" before and after trying to reproduce the
bug.  Do the processes die and get restarted (the process IDs will be different)?

-- Additional comment from redhat@nodata.co.uk on 2005-10-24 15:38 EST --
I originally tried a pkill evo to kill evolution, but I also tried evolution
--force-shutdown, both got rid of the processes.
The output from "pgrep -l evo" does not change before and after the hang.

Perhaps interestingly, the copy of the calendar entry works, but I have to
forcably kill evolution to see that.

-- Additional comment from rtlm10@gmail.com on 2006-04-24 14:50 EST --
I am seeing the same problem in FC5.  What can I do to help debug this issue. 
strace shows the process as just sitting at a FUTEX_WAIT
Comment 1 Matěj Cepl 2007-08-31 11:22: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 2 Matthew Barnes 2007-10-02 13:38:14 EDT
Closing as INSUFFICIENT_DATA.

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