GNOME Bugzilla – Bug 704914
Crash under e_ews_dump_file_attachment_from_soap_parameter()
Last modified: 2013-07-29 16:27:40 UTC
When deleting a different EWS user's calendar from the Calendar view (right click Calendar, select Delete), the evolution-data-server package crashes. All crash dumps and traces from ABRT reported here on Red Hat's BZ: https://bugzilla.redhat.com/show_bug.cgi?id=988610 Added to this BZ to track in dwmw2's BZ 703515. For a quick glace, package versions installed: evolution-3.8.4-1.fc19.x86_64 evolution-data-server-devel-3.8.4-1.fc19.x86_64 evolution-ews-debuginfo-3.8.4-1y.fc19.x86_64 evolution-help-3.8.4-1.fc19.noarch evolution-data-server-3.8.4-1.fc19.x86_64 evolution-ews-3.8.4-1y.fc19.x86_64
+ Trace 232297
That's a very odd call to g_strndup(). tmpfilename = (gchar *) content; tmpdir = g_strndup (tmpfilename, g_strrstr (tmpfilename, "/") - tmpfilename); We are *assuming* that the 'content' node has a filename which will contain a '/' character. That's a bit broken on Windows but generally ought to be OK on *nix I suppose... but evidently isn't. We have a hack to store the content to a disk file as it arrives from the network (to avoid storing it all in memory), and *replace* the content in the XML with the filename. That hack evidently isn't being triggered for this particular fetch...
*** Bug 704943 has been marked as a duplicate of this bug. ***
I'm wondering how that could happen. The attachment name "ATT29634" suggests it's an object, like a contact, or a message. OWA doesn't support such attachments, but the Outlook does. Nonetheless, even with that it survives without a crash for me. The call to e_ews_connection_get_attachments_sync() contains a correct path, ~196 letters long, which makes enough room for the temporary file name, thus it seems to me that the temporary file creation failed for some reason. This is the only way how I can reproduce it, by purging local cache and removing write mode from the ~/.cache/evolution/calendar
Yeah, I'm similarly confused about how it could happen. Output from cal-factory might have been enlightening. Perhaps it was caused by a cancellation while it was downloading the item?
Cancellation in this part is not checked, as far as I can tell, and I do not expect the soap being able to provide correct part while being cancelled. Though it's only a guess.
Created attachment 250379 [details] [review] ews patch for evolution-ews; This makes it not crash, for a price of no attachments being saved nor shown. Calendar's console is full of critical warnings in this case (I do not see how to propagate such error into UI, and still confirm that the operation finished "almost" successfully). The patch also clean-ups the directory separator hardcoding in the code, same as those weird g_strndup calls to get directory part of the path.
Created commit 6f13e6e (and commit 282dd64) in ews master (3.9.90+) (The commit 282dd64 fixes introduced memory leak.)