GNOME Bugzilla – Bug 681069
Crash under e_mapi_util_copy_binary_r()
Last modified: 2012-09-06 10:20:27 UTC
Created attachment 220149 [details] Backtrace Due to the fact that Abrt incorrectly combines unrelated backtraces into one RedHat Bugzilla bug, I need to register this bug in Gnome Bugzilla by hand. Forgive me if this bug is a duplicate. See attachment for the backtrace. evolution-3.4.3-2.fc17.x86_64 syncevolution-gtk-1.2.2-1.fc17.x86_64 evolution-help-3.4.3-2.fc17.noarch evolution-exchange-3.4.3-1.fc17.x86_64 syncevolution-libs-1.2.2-1.fc17.x86_64 evolution-data-server-3.4.3-1.fc17.x86_64 evolution-couchdb-0.5.91-10.fc17.x86_64 syncevolution-1.2.2-1.fc17.x86_64 evolution-NetworkManager-3.4.3-2.fc17.x86_64 evolution-mapi-3.4.3-5.fc17.x86_64
Looks like an evolution-mapi crash. Reassigning.
Thanks for a bug report. I'm pasting backtrace of crashing thread inline, for easier searching. Are you able to reproduce this reliably? I would be interested in detailed logs, to see what could happen here.
+ Trace 230646
Thread 1 (Thread 0x7fa8c3621700 (LWP 5588))
Hi Milan, I am sorry. I don't know how to reproduce this bug, and I don't have any (detailed) logs. kind regards, Egon
This happened on the initial fetching of calendar events from server to local machine. You can redo it if you close evolution, then stop evolution-calendar-factory and remove ~/.cache/evolution/calendar/<mapi-account-id>/ with all its subfolders. Then run the calendar factory from console, like this: $ MAPI_DEBUG=1 /usr/libexec/evolution-calendar-factory -w &>log.txt and then (after ~5 seconds) run evolution like this from another terminal: $ evolution -c calendar which will start evolution in Calendar view, where you can just open the MAPI calendar and wait until factory either crashes or evolution shows all events.
Were you able to gather log file from the steps in comment #4, please?
Hi Milan, Stopping evolution the normal way (using the Gui) does not stop evolution-calendar-factory: $ ps x|grep evol 1808 ? Sl 0:01 /usr/libexec/evolution-calendar-factory 1821 ? Sl 0:00 /usr/libexec/evolution-addressbook-factory evolution --force-shutdown also does not stop these processes. So I had to kill the processes from the command-line: $ kill 1808 $ kill 1821 $ rm -rf ~/.cache/evolution/calendar/<my_mapi_account>/ $ MAPI_DEBUG=1 /usr/libexec/evolution-calendar-factory -w &>log.txt (and in a second terminal) $ evolution -c calendar Evolution started, I enabled my MAPI account, entered my password in the popup, and it started to download my complete calendar. It did not crash while doing that. After I opened some appointments, Abrt popped up with a crash for evolution and a crash for evolution-data-server. The evolution Gui was still responsive after the crashes, so I closed it the normal way. The evolution crash did not show in the Abrt-gui, but the evolution-data-server did, so I sent it to the retrace server, but after succesfully uploading 14MB it seemed to hang on "Initializing virtual root"... The log.txt file you requested is ~128MB in size. I did a 'grep -i' on the words 'error', 'crash' and 'trace' but that does not produce any significant results. The output on the "evolution -c calender" terminal looks like this: =========================== ** (evolution:3302): CRITICAL **: categories_icon_theme_hack: assertion `filename != NULL && *filename != '\0'' failed Unknown parameter encountered: "max log size" Ignoring unknown parameter "max log size" Unknown parameter encountered: "load printers" Ignoring unknown parameter "load printers" Unknown parameter encountered: "cups options" Ignoring unknown parameter "cups options" Unknown parameter encountered: "writable" Ignoring unknown parameter "writable" Unknown parameter encountered: "guest ok" Ignoring unknown parameter "guest ok" Unknown parameter encountered: "writable" Ignoring unknown parameter "writable" e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results) (evolution:3302): calendar-gui-WARNING **: changes_view_ready_cb: Failed to get view: No such interface `org.gnome.evolution.dataserver.Calendar' on object at path /org/gnome/evolution/dataserver/Calendar/3181/3 (evolution:3302): calendar-gui-WARNING **: changes_view_ready_cb: Failed to get view: No such interface `org.gnome.evolution.dataserver.Calendar' on object at path /org/gnome/evolution/dataserver/Calendar/3181/3 (evolution:3302): libecal-WARNING **: Failed to dispose cal view: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gnome.evolution.dataserver.CalendarView' on object at path /org/gnome/evolution/dataserver/CalendarView/3181/66 (evolution:3302): libecal-WARNING **: Failed to dispose cal view: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gnome.evolution.dataserver.CalendarView' on object at path /org/gnome/evolution/dataserver/CalendarView/3181/67 (evolution:3302): libecal-WARNING **: Failed to dispose cal view: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gnome.evolution.dataserver.CalendarView' on object at path /org/gnome/evolution/dataserver/CalendarView/3181/68 (evolution:3302): libecal-WARNING **: Failed to dispose cal view: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gnome.evolution.dataserver.CalendarView' on object at path /org/gnome/evolution/dataserver/CalendarView/3181/52 (evolution:3302): libecal-WARNING **: Failed to dispose cal view: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gnome.evolution.dataserver.CalendarView' on object at path /org/gnome/evolution/dataserver/CalendarView/3181/53 (evolution:3302): libecal-WARNING **: Failed to dispose cal view: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gnome.evolution.dataserver.CalendarView' on object at path /org/gnome/evolution/dataserver/CalendarView/3181/54 (evolution:3302): libecal-WARNING **: Failed to dispose cal view: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gnome.evolution.dataserver.CalendarView' on object at path /org/gnome/evolution/dataserver/CalendarView/3181/39 (evolution:3302): libecal-WARNING **: Failed to dispose cal view: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gnome.evolution.dataserver.CalendarView' on object at path /org/gnome/evolution/dataserver/CalendarView/3181/55 ============================== -> Any thoughts? :) kind regards, Egon
Hi.. The retrace server took ages to return, but it logged a new bug: https://bugzilla.redhat.com/show_bug.cgi?id=853695 Hope this helps. kind regards, Egon
Good, you managed to reproduce the crash. The log.txt file probably contains many properties being printed, for downloaded components where each begins with line "e_mapi_cal_util_object_to_comp:", though I see I overlooked in your backtrace that this crash is about something else than I thought. I thought this is about recurrence blob parsing, but it isn't; it crashes when making a copy of Global Object ID binary structure. The interesting part is that the property was found, but the memory which holds it is corrupted, for some reason. I also see in your latest backtrace (and the comment above) that I was wrong about circumstances of the crash, because it happened when you were modifying object (or responding to a meeting invite), which I identified totally wrong in the first place. I'm sorry for that. I tested this on my machine and events/meetings I create in evolution are working fine, but if I try to edit meeting I created in OWA, then I get the same crash. Valgrind claims use of uninitialized memory with the same backtrace as your crash (I didn't have running valgrind with the evolution-created event/meeting, but I suppose it would crash anyway), thus I'm confirming this and I'll check what's wrong.
OK, I retested with current git master and it shows there the same issue, even with events created by evolution. It seems like I had just a luck with it not crashing earlier.
Created attachment 223281 [details] [review] ema patch for evolution-mapi; Aah, I got it. libmapi in OpenChange defines two different binary blob structures, one is Binary_r, the other is SBinary_short. The global IDs are stored with the later in the structure of properties within the backtrace, while I was using the former. The structures are not interchangeable, and when casting (void *) into it the data pointer was pointing into shifted memory, not the right place. I'll create a Fedora update of evolution-mapi and add to it the downstream bug from comment #0.
Created commit d0f2765 in ema master (3.5.92+)
(In reply to comment #10) > I'll create a Fedora update of evolution-mapi and add to it the downstream bug > from comment #0. Err, comment #7, it is.
Hi, I tested this problem against evolution-mapi-3.4.4-2.fc17.x86_64. It does not occur anymore. -> Great work! I'll add some karma to the fedora-project Bodhi. kind regards, Egon
Thanks.