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:
Any update on this bug?
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.
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?
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.
(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
(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.
(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
(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
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.
(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.
(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?
(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?
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.
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.
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"
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
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
Created attachment 695001 [details] Screenshots_RESOLVE_NAME_MAPI_error2
(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
Anybody tried to reproduce the bug with above steps?
The problem could be reproduced with above steps by waiting only 10 mints as well. No need to wait for 45 mints.
Created attachment 696011 [details] Timeout-error
(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.
Created attachment 696194 [details] Evolution bt when composing messagewindow is slow
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; } --------
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.
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.
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.
check the box "listen to server notification" and try to reproduce.
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.
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.
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
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.
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
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.
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.