Bug 587726 - [abrt] crash in evolution-2.30.1-2: check_server_for_object: exchange-mapi-cal-utils.c:1244
Summary: [abrt] crash in evolution-2.30.1-2: check_server_for_object: exchange-mapi-ca...
Status: CLOSED DUPLICATE of bug 537047
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: 13
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:052fa797072fda81fc8a5200fca...
Keywords:
: 588549 591618 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-30 17:41 UTC by Chad Feller
Modified: 2010-05-13 09:34 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-05-13 09:34:26 UTC


Attachments (Terms of Use)
File: backtrace (49.02 KB, text/plain)
2010-04-30 17:41 UTC, Chad Feller
no flags Details
valgrind ouput, no options passed to valgrind (3.60 KB, text/plain)
2010-05-12 17:28 UTC, Chad Feller
no flags Details
valgrind output, with --leak-check=full (830.18 KB, application/x-gzip)
2010-05-12 18:11 UTC, Chad Feller
no flags Details

Description Chad Feller 2010-04-30 17:41:46 UTC
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.

Comment 1 Chad Feller 2010-04-30 17:41:47 UTC
Created attachment 410553 [details]
File: backtrace

Comment 2 Chad Feller 2010-04-30 17:48:15 UTC
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.

Comment 3 Chad Feller 2010-04-30 17:50:33 UTC
(In reply to comment #2)

It would seem this crash is consistently reproducible.

Comment 4 Chad Feller 2010-04-30 17:52:37 UTC
Exchange Server is :
2007
mapi connector is:
evolution-mapi-0.30.1-1.fc13.x86_64

Comment 5 Chad Feller 2010-05-04 22:09:48 UTC
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.

Comment 6 Milan Crha 2010-05-05 10:52:35 UTC
*** Bug 588549 has been marked as a duplicate of this bug. ***

Comment 7 Milan Crha 2010-05-05 11:14:18 UTC
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.

Comment 8 Chad Feller 2010-05-12 17:28:55 UTC
Created attachment 413496 [details]
valgrind ouput, no options passed to valgrind

Comment 9 Chad Feller 2010-05-12 17:37:12 UTC
see bug# 591618 that ABRT just picked up.

Comment 10 Chad Feller 2010-05-12 18:11:41 UTC
Created attachment 413511 [details]
valgrind output, with --leak-check=full

Comment 11 Milan Crha 2010-05-13 08:19:58 UTC
*** Bug 591618 has been marked as a duplicate of this bug. ***

Comment 12 Milan Crha 2010-05-13 08:22:11 UTC
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)

Comment 13 Milan Crha 2010-05-13 09:34:26 UTC
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 ***


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