This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Thank you for your bug report. This issue was evaluated for inclusion
in the current release of Red Hat Enterprise Linux. Unfortunately, we
are unable to address this request in the current release. Because we
are in the final stage of Red Hat Enterprise Linux 6 development, only
significant, release-blocking issues involving serious regressions and
data corruption can be considered.

If you believe this issue meets the release blocking criteria as
defined and communicated to you by your Red Hat Support representative,
please ask your representative to file this issue as a blocker for the
current release. Otherwise, ask that it be evaluated for inclusion in
the next minor release of Red Hat Enterprise Linux.

I'm sorry for a late response. A way to debug this is to install debuginfo packages for evolution-data-server, evolution and evolution-mapi and get a backtrace of stuck evolution with a command like this:
   $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt
make sure the backtrace will not contain any sensitive information, like passwords, user names, email addresses and such, before you attach it here (I usually search for "pass" (quotes for clarity only) in a resulting file).

In any case, it'll be good to retest this after/if the rebase, see bug #883017, which contains many good fixes.

Took a little while to set up.  Our satellite don't provide the debuginfo channels, so I had to download some selected packages manually.  But after having done that, I was ready to debug and ... then it worked!  That's good, even if I feel a bit silly doing those manual downloads before I tried it. :-)

Maybe the bug has been fixed by some update in the mean time.  Or maybe something in our environment has changed, so it isn't triggered any more.  I don't know, but for the moment I can't reproduce the problem.  I'll start using the feature in Evolution again, and let you know if the bug reappears.

One option could be that the evolution-mapi calendar was still updating its content, in time when you tried to add the event, and the evolution got stuck on a request to create when the factory itself was doing other duties. The ~/.evolution/calendar/mapi... contains local cache of your calendar, and it serves for nothing but the cache, thus you can safely remove it. You should have evolution-data-server process closed during the cache purge. It also reminded me that a backtrace for running evolutiond-at-aserver-2.28 will help too, to see what both ends do.

I do not like to close this just because of "feeling it works fine now", but as long as it works for you, I suppose I can close and let's wait whether it'll strike back again or not. Thanks for the help with the investigation.

I'm not blaming you for closing.  It is hard to find a bug that can't be reproduced.  I'll be back with more details if it reappears.

Created attachment 752267 [details]
Backtrace following the instructions in comment 4

This happened again now, so I'm reopening, and attaching a backtrace as you asked for.

The exact operation I did was to try to move one appointment from a locally stored calendar to the MAPI calendar.  That caused Evolution to hang.

I believe I have debuginfo installed for all relevant packages except glibc.  As I mentioned, we don't have the debuginfo channel in our satellite, so I have downloaded things manually.  However, glibc-debuginfo depends on something called glibc-debuginfo-common.  That is not a standard name format for debuginfo packages AFAIK.  And I couldn't figure out how to find it via RHN.  Is there a way to get that package?

(In reply to Göran Uddeborg from comment #8)
> I believe I have debuginfo installed for all relevant packages except glibc.

Thanks for the update. The backtrace looks fine, glibc is not that important to me, I'm mostly interested in evoluton packages only. The backtrace you attached is for evoltuion itself, and it shows it waiting for a response from evolution-data-server-2.28, which is the blocking part here (it delays its response and causes this hang, because the calendar part does blocking I/O calls in the main thread, which, when blocked, makes UI part unresponsive during the wait period).

A backtrace for evolution-data-server-2.28 process will show what the evolution-mapi does.

Nonetheless, it's kind of known that evolution-mapi is slow on operations, probably due to the stack of libraries being involved, mainly openchange and samba.

By the way, do you know the Exchange server version you connect to?

But you said "pidof evolution". :-)

Seriously, the next time I'm able to hang evoution, I'll get backtraces of all the related processes.  (I don't have any reproducible case.  It often works nowdays.)

I don't know the Exchange version, but I'll find out.

(In reply to Göran Uddeborg from comment #10)
> But you said "pidof evolution". :-)

Yup, that's true. First see why evolution is hanged, then check what does the other part (I wasn't sure why is evolution hanged, now it showed it and thus we can debug forward). :)

> Seriously, the next time I'm able to hang evoution, I'll get backtraces of
> all the related processes.  (I don't have any reproducible case.  It often
> works nowdays.)

Thanks.

We are using Exchange 2007.

I haven't yet had Evolution hang since my last comment, but will let you know when it happens.

(In reply to Göran Uddeborg from comment #13)
> We are using Exchange 2007.
> 
> I haven't yet had Evolution hang since my last comment, but will let you
> know when it happens.

I'd say we would rather make this a Release Note, a Known Issue or something like that, because there is not much to be done. I think that what you see is just a conincidence of running cache update on the evolution-data-server side and request to save changes to the server from evolution. Due to thread unsafety of used libraries this cannot be done simultaneously, but the second operation waits for a finish of the first. If the first takes longer, then the second waits longer. Other part of the issue is that the request done on evolution's side is done on the main thread, which means the application is frozen during this waiting. We can try to address this particular use-case in evolution, but fixing calendar part in a general way is a complicated task, which should be done upstream first.

Of course, if your backtraces will show any deadlock on the data server side, then we have a real bug, though I'm afraid we have the above "waiting for the previous operation(s) to be finished, before being served" here.

Hi Göran, do you think my comment #14 makes sense? I tend to follow it, and basically close this bug due to the reasons I wrote there.

Yes, it makes sense.  And in addition, the bug, for whatever reason, seems to hit more and more rarely.  So go ahead.

OK, thanks. I just realized that the Exchange 2013 server finally dropped MAPI support, and only evolution-ews can be used with it, thus once (or if at all) your company will upgrade the Exchange server, you'll also get to other connector (a better one, from some point of views). The connector itself will not fix everything, especially not the evolution part of the problem, but the freezes should not be that often, and/or that long.