Bug 621943 - Trying to add a calendar event via MAPI hangs evolution
Summary: Trying to add a calendar event via MAPI hangs evolution
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: evolution-mapi (Show other bugs)
(Show other bugs)
Version: 6.0
Hardware: All Linux
low
medium
Target Milestone: rc
: ---
Assignee: Matthew Barnes
QA Contact: Desktop QE
URL:
Whiteboard:
Keywords: Reopened, RHELNAK
Depends On:
Blocks: 960054
TreeView+ depends on / blocked
 
Reported: 2010-08-06 15:08 UTC by Göran Uddeborg
Modified: 2013-09-19 17:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-07 05:01:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Backtrace following the instructions in comment 4 (13.09 KB, text/plain)
2013-05-23 15:31 UTC, Göran Uddeborg
no flags Details

Description Göran Uddeborg 2010-08-06 15:08:15 UTC
Description of problem:
Whenever I try to add a new meeting in a MAPI calendar, evolution hangs.  It doesn't crash, but it just stops doing anything.  The windows are not updated, if I hide one and expose it again, it is just grey.

Version-Release number of selected component (if applicable):
evolution-mapi-0.28.3-5.el6.x86_64
evolution-2.28.3-8.el6.x86_64
evolution-data-server-2.28.3-9.el6.x86_64

How reproducible:
Every time

Steps to Reproduce:
1.Connect to an Exchange server via MAPI
2.Add a event in the calendar

Actual results:
Complete hang.

Expected results:
The new meeting added to the calendar.

Additional info:
Would it help if I force evolution to dump core using SIGABRT, so I can get a backtrace?  Or how can I best help with more information?

Comment 2 RHEL Product and Program Management 2010-08-06 15:27:56 UTC
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. **

Comment 3 RHEL Product and Program Management 2010-08-18 21:22:02 UTC
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.

Comment 4 Milan Crha 2013-05-09 10:01:31 UTC
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.

Comment 5 Göran Uddeborg 2013-05-10 08:17:21 UTC
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.

Comment 6 Milan Crha 2013-05-10 16:26:25 UTC
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.

Comment 7 Göran Uddeborg 2013-05-10 16:53:06 UTC
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.

Comment 8 Göran Uddeborg 2013-05-23 15:31:52 UTC
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?

Comment 9 Milan Crha 2013-05-24 05:57:16 UTC
(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?

Comment 10 Göran Uddeborg 2013-05-24 13:46:00 UTC
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.

Comment 11 Milan Crha 2013-05-27 07:08:55 UTC
(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.

Comment 13 Göran Uddeborg 2013-05-29 09:20:45 UTC
We are using Exchange 2007.

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

Comment 14 Milan Crha 2013-06-07 11:52:49 UTC
(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.

Comment 16 Milan Crha 2013-08-06 13:21:41 UTC
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.

Comment 17 Göran Uddeborg 2013-08-06 13:55:24 UTC
Yes, it makes sense.  And in addition, the bug, for whatever reason, seems to hit more and more rarely.  So go ahead.

Comment 18 Milan Crha 2013-08-07 04:45:27 UTC
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.


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