Bug 903166 - ResolveNames MAPI Error
Summary: ResolveNames MAPI Error
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution-mapi
Version: 18
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-23 11:05 UTC by Samarjit Adhikari
Modified: 2014-02-05 15:42 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-05 15:42:40 UTC
Type: Bug


Attachments (Terms of Use)
MAPI_ERROR_SCREEN_SHOTS (771.35 KB, image/png)
2013-01-23 11:05 UTC, Samarjit Adhikari
no flags Details
Screenshots_RESOLVE_NAME_MAPI_error2 (420.00 KB, application/x-bzip2)
2013-02-08 10:04 UTC, Samarjit Adhikari
no flags Details
Timeout-error (250.00 KB, application/x-bzip2)
2013-02-11 10:39 UTC, Samarjit Adhikari
no flags Details
Evolution bt when composing messagewindow is slow (11.73 KB, text/plain)
2013-02-11 16:34 UTC, Samarjit Adhikari
no flags Details
ema patch (8.14 KB, patch)
2013-02-26 14:11 UTC, Milan Crha
no flags Details | Diff

Description Samarjit Adhikari 2013-01-23 11:05:37 UTC
Created attachment 685826 [details]
MAPI_ERROR_SCREEN_SHOTS

Description of problem:
Keeping evolution idle for 45 mints and after that failed to send email message

Version-Release number of selected component (if applicable):
Fedora-18
Evolution-3.6.2

How reproducible:
Steps given below

Steps to Reproduce:
1. Configure an exchange account to access it through evolution-mapi
2. open Evolution
3. keep evolution idle for 45 mints 
4. You can observe that new mails are coming to evolution
5. keep other net-browsing through firefox to make sure network is up
6. After 45 mints tried to send test mail to myself and got "ResolveNames MAPI Error" 

Screen shot attached.   

Actual results:
Got ResolveNameMAPI Error

Expected results:
Evolution should able to send message even after 45 mints

Additional info:

Comment 1 Samarjit Adhikari 2013-01-23 17:43:35 UTC
Any update on this bug?

Comment 2 Milan Crha 2013-01-24 12:33:54 UTC
Nope, no update on this yet. The error code is unknown to Google, thus I guess it's because a connection to addressbook got lost during the time (the openchange opens two connections, one for MAPI, another for addressbook/GAL) due to not being used, while the MAPI connection was used periodically when updating folders and so on.

Comment 3 Milan Crha 2013-01-24 17:08:13 UTC
I just tried with more than an hour running evolution, and I could send a message without any issue. Can it be some kind of setup on your server which kicks off long inactive connections?

Comment 4 Milan Crha 2013-01-28 11:51:52 UTC
I think this can be related to bug #903957, even if it doesn't crash for you. You might got disconnected from the server, it reconnected (I see something like that in the logs you sent me privately, even I do not see there the error number you attached here as a screenshot), but didn't retry to finish the operation. Otherwise the code and the logs seem fine, on the first look.

Comment 5 Samarjit Adhikari 2013-01-28 12:09:38 UTC
(In reply to comment #4)
> I think this can be related to bug #903957, even if it doesn't crash for
> you. You might got disconnected from the server, it reconnected (I see
> something like that in the logs you sent me privately, even I do not see
> there the error number you attached here as a screenshot), but didn't retry
> to finish the operation. Otherwise the code and the logs seem fine, on the
> first look.

Could be. I had a feeling that it was reconnecting but failing to finish some operation. I shall try the fix on evolution-data server

Comment 6 Samarjit Adhikari 2013-02-06 07:24:57 UTC
(In reply to comment #4)
> I think this can be related to bug #903957, even if it doesn't crash for
> you. You might got disconnected from the server, it reconnected (I see
> something like that in the logs you sent me privately, even I do not see
> there the error number you attached here as a screenshot), but didn't retry
> to finish the operation. Otherwise the code and the logs seem fine, on the
> first look.

I tried with latest evolution 3.6.4 with mapi, even though i got same error.
I have compiled the latest code base from git and tried. It has the e-d-s changes as well. A little google around the error gives me following links [1] and [2].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=244222
[2] http://social.msdn.microsoft.com/Forums/en-SG/vbgeneral/thread/d8bd6e4b-9894-43be-ad42-902955da3956

I am not sure if above links helps for you.

Comment 7 Samarjit Adhikari 2013-02-06 07:27:21 UTC
(In reply to comment #4)
> I think this can be related to bug #903957, even if it doesn't crash for
> you. You might got disconnected from the server, it reconnected (I see
> something like that in the logs you sent me privately, even I do not see
> there the error number you attached here as a screenshot), but didn't retry
> to finish the operation. Otherwise the code and the logs seem fine, on the
> first look.

Not actually. With latest 3.6.4 calender-factory issue [1] got fixed.

[1]https://bugzilla.redhat.com/show_bug.cgi?id=903045

Comment 8 Samarjit Adhikari 2013-02-06 07:31:23 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > I think this can be related to bug #903957, even if it doesn't crash for
> > you. You might got disconnected from the server, it reconnected (I see
> > something like that in the logs you sent me privately, even I do not see
> > there the error number you attached here as a screenshot), but didn't retry
> > to finish the operation. Otherwise the code and the logs seem fine, on the
> > first look.
> 
> I tried with latest evolution 3.6.4 with mapi, even though i got same error.
> I have compiled the latest code base from git and tried. It has the e-d-s
> changes as well. A little google around the error gives me following links
> [1] and [2].
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=244222
> [2]
> http://social.msdn.microsoft.com/Forums/en-SG/vbgeneral/thread/d8bd6e4b-9894-
> 43be-ad42-902955da3956
> 
> I am not sure if above links helps for you.

While i got the "ResolveNames MAPI Error" i switched back to calender tab and there was following error. [1], but evolution still able to download mails.

[1]Failed to open folder: OpenFolder: MAPI error MAPI_E_CALL_FAILED (0x80004005) occurred

Comment 9 Milan Crha 2013-02-06 08:48:29 UTC
Thanks for the update and all the testing. The two links seem to me unrelated, as you can send messages through evolution-mapi after evolution's start, but it fails when evolution is running longer (45+ minutes in your case). As I tried to reproduce it, but it worked fine for me, then I guess this is more related to your server, which may disconnect one part of the connection which was not used for some time. This is still just a guess, though.

Comment 10 Milan Crha 2013-02-06 08:50:32 UTC
(In reply to comment #8)
> [1]Failed to open folder: OpenFolder: MAPI error MAPI_E_CALL_FAILED
> (0x80004005) occurred

Such error can happen on an unexpected disconnect from the server, when the local connection still thinks it's connected, but it isn't on the server side.

Comment 11 Samarjit Adhikari 2013-02-06 10:26:20 UTC
(In reply to comment #10)
> (In reply to comment #8)
> > [1]Failed to open folder: OpenFolder: MAPI error MAPI_E_CALL_FAILED
> > (0x80004005) occurred
> 
> Such error can happen on an unexpected disconnect from the server, when the
> local connection still thinks it's connected, but it isn't on the server
> side.

Is it possible to made a fix to reopen a addressbook/GAL connection if MAPI connection already is in use?

Comment 12 Samarjit Adhikari 2013-02-06 10:28:25 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)
> > > [1]Failed to open folder: OpenFolder: MAPI error MAPI_E_CALL_FAILED
> > > (0x80004005) occurred
> > 
> > Such error can happen on an unexpected disconnect from the server, when the
> > local connection still thinks it's connected, but it isn't on the server
> > side.
> 
> Is it possible to made a fix to reopen a addressbook/GAL connection if MAPI
> connection already is in use?

Or something configurable to refresh addressbook connection periodically?

Comment 13 Milan Crha 2013-02-06 15:26:13 UTC
Hmm, those two connections are provided by OpenChange transparently, and it's just both or none there. The most confusing thing for me is the error code it gives you, the 0x277a7f23, even Google never heard about it, which is suspicious.

Could you try to capture the
   $ LIBMAPI_DEBUG=15 evolution &>log.txt
log, this time let it running all the 45 minutes, until you actually get the ResolveNames error, thus the log will contain it. And even try multiple times, ideally if you send a message to yourself at the beginning, thus there will be shown what connection is used and such, please? Maybe it'll help. The only thing is that the log will be awfully long and will show all what you'll do/download/send during the logging. Please send it to me privately again.

Comment 14 Samarjit Adhikari 2013-02-07 02:51:54 UTC
I observed 2 issues in collected log.

1) Resolve name issue.
   Towards the end of the log if you search for string 'NspiResolveNamesW' you will observe the MAPI packect error "MAPI_E_NOT_FOUND". I believe this is the reason i got the resolve name error.


2) Evolution is slow in response after 45 mints even when i open a mail composer window. This is due to error "Cannot get book from factory: Timeout was reached" and i got "Failed to open folder: OpenFolder: MAPI error MAPI_E_CALL_FAILED" in addressbook window.

Hope this helps.

Comment 15 Samarjit Adhikari 2013-02-07 07:20:52 UTC
One thing i forget to mention that i was using LDAP server for my contacts and it was my default addressbook for searching any contact.Autocompletion of addresses is also enabled with this LDAP account. i have observe that when LDAP connection gets timeout, composing mail messages become slow (i.e. Clicking New mail message and after long time, getting the composer window), searching of contacts in LDAP account is no more working finnaly sending out messages invokes
"ResolveNames MAPI Error"

Comment 16 Milan Crha 2013-02-07 10:13:26 UTC
Thanks for the log. It still doesn't contain the failed ResolveNames call, those MAPI_E_NOT_FOUND you mentioned are OK, it's only on particular properties, which means that these were not found or stored with the resolved contact. The MAPI_E_CALL_FAILED comes from evolution-addressbook-factory process, I guess the server disconnected and this is the response on the disconnection. It may reconnect silently, though.

About the slowness on composer open, it might be related to some memory leaks. Few of them were addressed in an upstream bug [1], while there can be more issues. I think that your extreme slowness is due to evolution-addressbook-factory, it is stuck on some operation probably, not responding to evolution's requests. If it happens to you again, please get a backtrace of the running factory, maybe it'll show what it does (debug info packages of the same version as the binary evolution-data-server and evolution-mapi packages is required, to get usable backtrace. You can get the backtrace with command like this:
   $ gdb --batch --ex "t a a bt" -pid=`pidof evolution-addressbook-factory` &>bt.txt
Please make sure it'll not contain any passwords (I usually search for "pass" (quotes for clarity only) in it, to check whether it's there), or other private information before attaching it here, or sending to me directly.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=689476

Comment 17 Samarjit Adhikari 2013-02-07 15:43:39 UTC
As i am using the latest Evolution code base 3.6.4+ i already have the code changes for [1]. Still it was slow.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=689476

Comment 18 Samarjit Adhikari 2013-02-08 10:04:38 UTC
Created attachment 695001 [details]
Screenshots_RESOLVE_NAME_MAPI_error2

Comment 19 Samarjit Adhikari 2013-02-08 10:09:07 UTC
(In reply to comment #18)
> Created attachment 695001 [details]
> Screenshots_RESOLVE_NAME_MAPI_error2

Evolution 3.6.4+
I found steps to reproduce the issue with 100% accuracy.

1) open mail composer.
2) write some data, indicating time as screen shot shows.
3) Wait for another 10 mints 
4) write some data indicating time as screen shot shows
5) repeat 2-4 steps 4/5 times like screen shots.
6) After 45 mints of opening the composer try to send mail.
   it should show the error message

Comment 20 Samarjit Adhikari 2013-02-11 02:11:27 UTC
Anybody tried to reproduce the bug with above steps?

Comment 21 Samarjit Adhikari 2013-02-11 08:39:15 UTC
The problem could be reproduced with above steps by waiting only 10 mints as well. No need to wait for 45 mints.

Comment 22 Samarjit Adhikari 2013-02-11 10:39:25 UTC
Created attachment 696011 [details]
Timeout-error

Comment 23 Samarjit Adhikari 2013-02-11 10:43:35 UTC
(In reply to comment #22)
> Created attachment 696011 [details]
> Timeout-error

Very interesting observation.

1) open a composer windows 
2) Do not put any addr in "TO"/"CC" field 
3) add body content as current time
4) Wait for 10 mints
5) add body content as current time
6) try to add addr in "To"/"CC" field
7) It will show time out has reached and if you put any e-mail address manually and try to send it will throw "ResolveName MAPI error"

Stack trace of "evolution-address" factory has been attached.

Comment 24 Samarjit Adhikari 2013-02-11 16:34:12 UTC
Created attachment 696194 [details]
Evolution bt when composing messagewindow is slow

Comment 25 Samarjit Adhikari 2013-02-12 10:46:21 UTC
Added some debug print in evolution-mapi code and got following regarding resolve name issue

"
Could not send message: ResolveNames (add_object_recipients): MAPI error  (0x4cd51ec3) occurred"."

File: src/libexchangemapi/e-mapi-connection.c
Function: add_object_recipients(.....)

[Code]
------

    ms = ResolveNames (priv->session, users, tags, &rows, &flagList, MAPI_UNICODE); <--  Here call ResolveNames failed.
    if (ms != MAPI_E_SUCCESS) {
        make_mapi_error (perror, "ResolveNames (add_object_recipients)", ms);
        goto cleanup;
    }
--------

Comment 26 Milan Crha 2013-02-15 07:59:15 UTC
Thanks for the update and the log (being sent privately). I see at the end of the log that the NspiResolveNamesW is sent, but the response is not logged for some reason, instead of it it continues with object release request, which is when closing a message object and a folder object. An interesting thing is that the error code changes, which may mean that it's:
a) a locally recognized issue
b) the error code is not set, there can be used an uninitialized memory, probably

I'll test your steps here soon, I only had other work to be done before this.

Comment 27 Milan Crha 2013-02-15 11:23:28 UTC
I left the composer opened for 40 minutes, but it was working as expected even after that time. i was able to search my MAPI GAL, and send a message with it to someone else. Either your setup is slightly different, or the server behaves differently, though it might not explain the missing part of the log.

I have installed evolution-3.6.3-2, evolution-dat-aserver-3.6.3-1 and evolution-mapi-3.6.3-1.

Comment 28 Milan Crha 2013-02-15 11:26:35 UTC
One thought, though probably useless, if there is used any uninitialized memory, then valgrind may show it, but running evolution under it is very slow due to all the memory checking. With installed valgrind you can run evolution like this:

   $ valgrind --num-callers=50 evolution &>log.txt

and then try to reproduce the issue, but as I said, it'll be awfully slow.

Comment 29 Samarjit Adhikari 2013-02-23 12:34:24 UTC
check the box "listen to server notification" and try to reproduce.

Comment 30 Milan Crha 2013-02-26 09:46:38 UTC
I tried with that, composer had been opened for an hour, and it still works as expected. I guess it does some server setting, I cannot explain it otherwise.

Comment 31 Milan Crha 2013-02-26 10:02:15 UTC
Aha, I _can_ reproduce this. I was searching for a contact which was in my GAL cache already, thus it seemed like working, but when I hit Send, it failed on Resolve Names, with some strange code.

I'll try to cook a patch I suggested on evolution-hackers mailing list and then return back to you. Thanks for you patience on this.

Comment 32 Milan Crha 2013-02-26 11:40:09 UTC
I managed to create a patch which always creates a new connection when sending a message, which makes sending significantly slower here, but it can be different with other servers. I created a test build [1] with the patch include, I'll appreciate if you could test it. Thanks in advance.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5057030

Comment 33 Milan Crha 2013-02-26 14:11:08 UTC
Created attachment 702873 [details]
ema patch

Here's my evoluton-mapi patch. It's not in git sources yet. I thought creating a test package will be easier for you, but I see it's not (based on the evolution-hackers mailing list). I can reproduce something similar with openchangeclient too, I'll report it to them as well.

Comment 34 Milan Crha 2013-02-26 16:03:13 UTC
I opened an OpenChange ticket for this [1], because I'm able to reproduce this in openchangeclient too, after some tweaks of it.

[1] http://tracker.openchange.org/issues/417

Comment 35 Fedora End Of Life 2013-12-21 10:44:19 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 36 Fedora End Of Life 2014-02-05 15:42:43 UTC
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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