GNOME Bugzilla – Bug 615086
evolution process termination at fetching mail operation
Last modified: 2011-05-19 13:16:44 UTC
Compiled from source evolution-2.30.0.1, evolution-mapi-0.30.0 OS Ubuntu Karmic 9.10. Headers and libs for libmapi used from openchange-0.9-COCHRANE source. when running in console it got errors like: PR_DISPLAY_TYPE_ERROR: 0x8004010f PR_OBJECT_TYPE_ERROR: 0x8004010f PR_ORG_ADDR_TYPE_ERROR: 0x8004010f PR_ORG_EMAIL_ADDR_ERROR: 0x8004010f PR_OBJECT_TYPE_ERROR: 0x8004010f PR_ORG_ADDR_TYPE_ERROR: 0x8004010f I omitted other outputs because most of it contain email private addresses.
Last message in output is "Aborted". Like without returning "segmentation fault"
Thanks for taking the time to report this bug. Without a stack trace from the crash it's very hard to determine what caused it. Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance! If you don't bug-buddy pop up when application crash, you can get traces using gdb. see http://live.gnome.org/GettingTraces/Details#gdb-not-yet-running for details about how to do this
Created attachment 158300 [details] (gdb) trace apply all bt output
I made trace see attachment in message above.
when I repeated 'run' command in gdb shell, after executing code, window of evolution was frozen, and gdb prompted 'InboProgram received signal SIGABRT, Aborted' I repeated it again and got another prompt 'Program received signal SIGSEGV, Segmentation fault.' Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb07c6b70 (LWP 10688)] 0xb6b3f071 in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) thread apply all bt
+ Trace 221312
Thread 20 (Thread 0xb07c6b70 (LWP 10688))
Thanks for the traces.
*** Bug 621154 has been marked as a duplicate of this bug. ***
Thanks for a bug report. I didn't see this myself (yet), but from a duplicate bug I see that it's reproducible also with the latest openchange, which is not good. I would like to ask you to try to reproduce this under valgrind, whether it'll show something. Also, is it possible it depends on some special message, but other messages are opened just fine? You can delete your local message cache in ~/.evolution/mail/mapi/<account>/folders/ when evolution is off to for a refetch of the message.
Created attachment 163396 [details] valgrind output I purged the files as per Milan's last comment and reran under valgrind. I wasn't able to reproduce the problem (although the GAL still doesn't work); my MAPI mail accounts behave as I'd expect.
*** Bug 615947 has been marked as a duplicate of this bug. ***
> Conditional jump or move depends on uninitialised value(s) > at 0xC57F5D6: mapi_response_destructor (emsmdb.c:273) > by 0xCB8C433: _talloc_free_internal (talloc.c:600) Hmm, apart of memory issues within header_decode_atom called from camel_header_contentid_decode, I see only one issue coming from openchange, the above one. I do not know openchange good enough to be able to tell for sure whether it's a cause of the issue or not, I hoped it'll claim something in that OpenMessage call, somewhere in the above backtrace. With respect of those camel invalid reads, it would be great if you can find the value for the Content-ID header it was trying to parse, the only thing I know about it is that it contained one of ".[]" after the '@' letter, but nothing more. Feel free to ping me on a guide for a debugging hint. Thanks.
Do we want to keep the bug open, there is no update since long time ?
Probably not, unless David or Pavel have any update on this, the best with 0.32.0.
I just tried activating my mapi account (in the git/master of about 1 week ago). Bugbuddy pops up and I get: Distribution: Slackware Slackware 12.2.0 Gnome Release: 2.32.0 2010-09-27 (GARNOME) BugBuddy Version: 2.32.0 System: Linux 2.6.34-rc5-ge520683 #2 SMP PREEMPT Tue Jun 8 13:13:01 EDT 2010 i686 X Vendor: The X.Org Foundation X Vendor Release: 10900000 Selinux: No Accessibility: Disabled GTK+ Theme: Default Icon Theme: gnome GTK+ Modules: canberra-gtk-module, gnomesegvhandler Memory status: size: 260075520 vsize: 260075520 resident: 63660032 share: 30474240 rss: 63660032 rss_rlim: 18446744073709551615 CPU usage: start_time: 1287499509 rtime: 2190 utime: 1750 stime: 440 cutime:63 cstime: 7 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/opt/garnome-svn-2.31.92/bin/evolution' [Thread debugging using libthread_db enabled] [New Thread 0xace9fb90 (LWP 32360)] [New Thread 0xaae2fb90 (LWP 32359)] [New Thread 0xa7df6b90 (LWP 32357)] [New Thread 0xac69fb90 (LWP 32035)] [New Thread 0xad8b7b90 (LWP 32034)] [New Thread 0xae119b90 (LWP 32019)] [New Thread 0xae919b90 (LWP 32018)] [New Thread 0xb59c8b90 (LWP 32013)] 0xb5df2f74 in __lll_lock_wait () from /lib/libpthread.so.0
+ Trace 224223
Thread 4 (Thread 0xa7df6b90 (LWP 32357))
Inferior 1 [process 32011] will be detached. Quit anyway? (y or n) [answered Y; input not from terminal]
Hmm, crash inside talloc and MAPIInitialize. I didn't see crash inside MAPIInitialize for quite some time now. Either the mapi-profiles.ldb is borked, which doesn't seem to be, or something else. What is your openchange revision, please?
svnversion shows 2200, but that is probably newer than what I'm running. (I'm in the process of buiding gome 2.91.1 and my build scripts first update everything, moreover, the build is not going well).
David, did you get the crash again with updated build ?
I mived to Ubuntu 10.10 Maveric and compiled 2.32.1 evolution. in evolution-mapi-2.32.1 I am not observing same behavior.
i think 2.32.1 is fixing that issue. 2.32.0 - had issues sometimes with fetching messages from exchange but not crush evolution completely. 2.32.1 fix my bugs. And also forgot to mention important thing - compiled mapi with using compiled from source openchange-0.10-NOMAD libs.
also openchange-0.10-NOMAD comile smoother then 0.9. I had less trouble to fix dependencies. Plus 0.9 was nevere normally finish compilation except when I did make installib only libs were nomrally compiled and installed. with 0.10 full compilation going well - may be openchange code also affect mapi. But 0.10 is fresh as 2.32 I think.
(In reply to comment #20) > may be openchange code also affect mapi. But 0.10 is fresh as 2.32 I think. It definitely is affecting mapi. Even it is only 0.9 to 0.10, then those two versions are about a year (or more) from each other, and there landed quite many fixes in the time between these two versions of openchange.
I followed this up from Bug 650352, noticed that the bug is in the RESOLVED FIXED state although segfaults are still occurring with evolution 2.32.1-1 and evolution-mapi 0.32.1-1. Occasionally a SIG6 is thrown, but it typically drops SIG11. This occurs every time I try to synchronize Evolution with corporate Exchange server - all subfolders can sync without issue, but Inbox and Sent both crash when synchronizing. This seems to happen at the same point every time, but I can't pinpoint if a particular message is triggering it. I can recreate the issue and submit more traces if it will help troubleshoot.
(In reply to comment #22) > I followed this up from Bug 650352, You mean probably Red hat bugzilla bug #650352, which is in Closed/Upstream state, moved to bug #634290 > ... > I can recreate the issue and submit more traces if it will help troubleshoot. Please see comment #19 and comment #20, Pavel said it's working for him when he uses openchange 0.10 and compiles evolution-mapi 0.32.1 from sources. The openchange 0.10 is not part of Fedora, because it depends on newer samba4, which has new issues. So we are stuck a bit.
Not sure what was changed. Might got some repository update for camel or etc. It is started to appear in my Ubuntu Maveric on Jan 14 2011. Now Fetching of email is terminating. evolution still running but its no longer getting new messages. I was happy to use evolution before today. Getting error 'MAPI error MAPI_E_CALL_FAILED (0x80004005)'. here the outputs errors: (evolution:1083): libexchangemapi-CRITICAL **: make_mapi_error: assertion `*perror == NULL' failed (evolution:1083): camel-mapi-provider-WARNING **: Could not get folder list (OpenFolder: MAPI error MAPI_E_CALL_FAILED (0x80004005) occurred) evolution-mail-Message: Error occurred while existing dialogue active: Fetching items failed: OpenFolder: MAPI error MAPI_E_CALL_FAILED (0x80004005) occurred (evolution:1083): camel-WARNING **: Could not open converter for 'CP50220' to 'UTF-8' charset (evolution:1083): camel-WARNING **: No from set for message evolution-mail-Message: Error occurred while existing dialogue active: Fetching items failed: OpenMessage: MAPI error MAPI_E_CALL_FAILED (0x80004005) occurred (evolution:1083): camel-mapi-provider-WARNING **: mapi_sync_deleted_free: Fetching items failed: OpenMessage: MAPI error MAPI_E_CALL_FAILED (0x80004005) occurred
compiled openchange from SVN trunk and getting 'Segmentation fall' The compiled version from tar ball 0.10-NOMAD is not returning segmentation fall but return error described in my previous post. Something was changed... in my OS, not sure what.
Note that openchange depends on samba4. You can try "make samba-git" in openchange checkout to get the latest samba4 and then build openchange itself with it. There was some changes with respect of crashing in krb5 code of samba4 done recently, but I do not know if it's your case, because no crashing function/backtrace provided. Either way, one very important thing about this: does openchangeclient also crashes when accessing your Inbox or Sent (or any other folder which makes trouble for you)? For Inbox you can run these commands on console: a) check the profile name you've configured in evolution [1]: $ mapiprofile -f $LDBFILE --list b) run the openchange client: $ openchangeclient -f $LDBFILE -p $PROFILENAME -P $PASSWORD --fetchmail [1] LDBPREFIX depends on your version, it's either ~/.evolution/mapi-profiles.ldb or ~/.local/share/evolution/mapi-profiles.ldb
Pavel, ping, any update for the bug ?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
Workaround for this bug is run evolution once in MAPI debug mode: #> export MAPI_DEBUG=10 #> evolution Somehow in this mode evolution-mapi fixing message index. After evolution successfully synced with exchange server I usually close it and run in regular mode.