abrt 1.0.9 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: evolution comment: was opening a message in evolution, this particular message happened to be an "Accepted" meeting request. component: evolution executable: /usr/bin/evolution global_uuid: 052fa797072fda81fc8a5200fcab6292b29abd7b kernel: 2.6.33.2-57.fc13.x86_64 package: evolution-2.30.1-2.fc13 rating: 4 reason: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV) release: Fedora release 13 (Goddard) How to reproduce ----- 1. open exchange message in evolution 2. 3.
Created attachment 410553 [details] File: backtrace
Package: evolution-2.30.1-2.fc13 Architecture: x86_64 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1. opened exchange message in evolution 2. 3. Comment ----- ABRT should report this as bug #587726, as I was doing the same thing - opening a meeting "Accepted" message in evolution.
(In reply to comment #2) It would seem this crash is consistently reproducible.
Exchange Server is : 2007 mapi connector is: evolution-mapi-0.30.1-1.fc13.x86_64
Package: evolution-2.30.1-2.fc13 Architecture: x86_64 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1. opening a meeting request in evolution. 2. 3. Comment ----- opening meeting request in evolution causes this crash. I was able to reproduce this crash consistently.
*** Bug 588549 has been marked as a duplicate of this bug. ***
Thanks for a bug report. This is filled already as bug #537047, which is moved upstream. I was unable to reproduce it myself. Could you try to reproduce this under valgrind, please? It'll be awfully slow, but maybe it'll show us some pointers what happend to underlying data. Thanks in advance.
Created attachment 413496 [details] valgrind ouput, no options passed to valgrind
see bug# 591618 that ABRT just picked up.
Created attachment 413511 [details] valgrind output, with --leak-check=full
*** Bug 591618 has been marked as a duplicate of this bug. ***
Thanks for an update. So the valgrind thinks the memory it tries to access is not known, for some reason: Thread 7: Invalid read of size 8 ==2034== at 0xEF37AB3: check_server_for_object (exchange-mapi-cal-utils.c:1244) ==2034== by 0xEF3962C: exchange_mapi_cal_util_camel_helper (exchange-mapi-cal-utils.c:1298) ==2034== by 0xED18323: fetch_item_cb (camel-mapi-folder.c:1346) ==2034== by 0xEF32C8A: exchange_mapi_connection_fetch_item (exchange-mapi-connection.c:1567) ==2034== by 0xED196D4: mapi_folder_get_message (camel-mapi-folder.c:1892) ==2034== by 0x3B8BA30426: camel_folder_get_message (camel-folder.c:1128) ==2034== by 0x3B8507C186: get_message_exec (mail-ops.c:1858) ==2034== by 0x3B85078BB7: mail_msg_proxy (mail-mt.c:471) ==2034== by 0x3B6D466D4A: g_thread_pool_thread_proxy (gthreadpool.c:315) ==2034== by 0x3B6D464E83: g_thread_create_proxy (gthread.c:1893) ==2034== by 0x3B6C807760: start_thread (pthread_create.c:301) ==2034== by 0x3B6BCE150C: clone (clone.S:115) ==2034== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==2034== ==2034== ==2034== Process terminating with default action of signal 11 (SIGSEGV) ==2034== Access not within mapped region at address 0x8 ==2034== at 0xEF37AB3: check_server_for_object (exchange-mapi-cal-utils.c:1244) ==2034== by 0xEF3962C: exchange_mapi_cal_util_camel_helper (exchange-mapi-cal-utils.c:1298) ==2034== by 0xED18323: fetch_item_cb (camel-mapi-folder.c:1346) ==2034== by 0xEF32C8A: exchange_mapi_connection_fetch_item (exchange-mapi-connection.c:1567) ==2034== by 0xED196D4: mapi_folder_get_message (camel-mapi-folder.c:1892) ==2034== by 0x3B8BA30426: camel_folder_get_message (camel-folder.c:1128) ==2034== by 0x3B8507C186: get_message_exec (mail-ops.c:1858) ==2034== by 0x3B85078BB7: mail_msg_proxy (mail-mt.c:471) ==2034== by 0x3B6D466D4A: g_thread_pool_thread_proxy (gthreadpool.c:315) ==2034== by 0x3B6D464E83: g_thread_create_proxy (gthread.c:1893) ==2034== by 0x3B6C807760: start_thread (pthread_create.c:301) ==2034== by 0x3B6BCE150C: clone (clone.S:115)
Ah, I think I got it, the call to exchange_mapi_util_resolve_named_prop failed for some reason, returning NULL, and then it crashed when dereferencing NULL pointer. I added a check for this situation in the code, thus should be fine. See the upstream bug [1] for more updates. Thanks for helping with investigation. Note the 0.31.1 hasn't this code, it has there other changes. [1] https://bugzilla.gnome.org/show_bug.cgi?id=601680 *** This bug has been marked as a duplicate of bug 537047 ***