+++ 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 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.uk on 2005-10-24 14:06 EST -- Please can I have a evolution-connector-debuginfo package? -- Additional comment from dmalcolm 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.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.uk on 2005-10-24 15:03 EST -- Created an attachment (id=120317) requested stack traces -- Additional comment from dmalcolm 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.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 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
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.
Closing as INSUFFICIENT_DATA.