GNOME Bugzilla – Bug 675796
[abrt] Assertion abort in ews_decode_oab_prop()
Last modified: 2013-08-29 05:51:08 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.
+ Trace 230206
Thread 6 (Thread 0x7f793b5f1700 (LWP 2619))
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.
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.
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.
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
Created commit 7ac1ec9 in ews master (3.9.91+)
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.
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 :)