After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 675796 - [abrt] Assertion abort in ews_decode_oab_prop()
[abrt] Assertion abort in ews_decode_oab_prop()
Status: RESOLVED FIXED
Product: evolution-ews
Classification: Other
Component: Contacts (Global Address List)
3.2.x
Other Linux
: Normal critical
: ---
Assigned To: Evolution EWS maintainer(s)
Evolution EWS maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2012-05-10 09:23 UTC by Milan Crha
Modified: 2013-08-29 05:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ews patch (2.01 KB, patch)
2013-08-28 11:20 UTC, Milan Crha
committed Details | Review

Description Milan Crha 2012-05-10 09:23:19 UTC
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=820243

[abrt] evolution-data-server-3.2.3-3.fc16: __GI_raise: Process /usr/libexec/e-addressbook-factory was killed by signal 6 (SIGABRT)

libreport version: 2.0.8
abrt_version:   2.0.7
backtrace_rating: 4
cmdline:        /usr/libexec/e-addressbook-factory
comment:        I attempted send a mail using the ews backend
crash_function: __GI_raise
executable:     /usr/libexec/e-addressbook-factory
kernel:         3.3.4-3.fc16.x86_64
reason:         Process /usr/libexec/e-addressbook-factory was killed by signal
6 (SIGABRT)
time:           2012-05-09T15:04:50 CEST

Core was generated by `/usr/libexec/e-addressbook-factory'.
Program terminated with signal 6, Aborted.

Thread 6 (Thread 0x7f793b5f1700 (LWP 2619))

  • #0 read
    at ../sysdeps/unix/syscall-template.S line 82
  • #1 read
    at /usr/include/bits/unistd.h line 45
  • #2 unix_signal_helper_thread
    at gmain.c line 4567
  • #3 g_thread_create_proxy
    at gthread.c line 1962
  • #4 start_thread
    at pthread_create.c line 309
  • #5 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 115

Comment 1 Seán de Búrca 2012-06-24 22:55:55 UTC
I received a similar trace attempting to download the Global Address List for my organization. The property it crashed on had ID 0x8cdb000d, PidTagAddressBookDistributionListRejectMessagesFromDLMembers. Because it is of type PT_OBJECT, which is unimplemented, the switch statement in ews_decode_oab_prop() defaults and asserts. There is a list of potential property types at http://msdn.microsoft.com/en-us/library/bb446176.aspx and, since many of these are unimplemented, they could potentially reach the assert.

Is there any reason that, given that the data types for each property type are listed, implementing all remaining property types would be non-trivial? If not, I would be happy to submit a patch.
Comment 2 Milan Crha 2012-06-25 09:38:33 UTC
Reading those multi-value data structs can be considered non-trivial, but maybe not that much. If you feel you can handle it then feel free to provide a patch, I'll be happy to review it. Otherwise just let me know and I can try to give it a shot myself.
Comment 3 Seán de Búrca 2012-07-03 06:09:45 UTC
After reviewing the existing code, I'm concerned that any attempt I made to implement these would have a high potential for introducing buggy code. Much of the reasoning behind certain code blocks is unclear to me. It would probably be better if you made the appropriate changes. For reference, http://hands.com/~lkcl/emsabp.idl contains an expanded mapping between property type IDs and names.
Comment 4 Milan Crha 2013-08-28 11:20:23 UTC
Created attachment 253366 [details] [review]
ews patch

for evolution-ews;

I tried to reproduce this first, but I failed after many attempts with different servers. Anyway, I studied [1] and realized that the ews' oab decoder supports all types written in the [1], except of the PtypObject. These are not encoded in the OAB file at all, according to [2], there is only available its presence or absence, from what I understood. That means that this patch should fix the crash, but I cannot test it properly right now. I'll commit, and if you'll have time, it'll help to give it a try against your offline GAL.

[1] http://msdn.microsoft.com/en-us/library/cc463914%28v=exchg.80%29.aspx
[2] http://msdn.microsoft.com/en-us/library/gg671985%28v=EXCHG.80%29.aspx
Comment 5 Milan Crha 2013-08-28 11:23:59 UTC
Created commit 7ac1ec9 in ews master (3.9.91+)
Comment 6 Seán de Búrca 2013-08-28 15:02:25 UTC
Unfortunately, I no longer have access to the GAL in question. However, a glance at the code suggests it would resolve the problem I was experiencing.
Comment 7 Milan Crha 2013-08-29 05:51:08 UTC
OK, thanks. The testing would be to see whether I deciphered the MSDN documentation properly, aka whether the byte order is not shifted in the file. We'll see once someone will report an issue :)