GNOME Bugzilla – Bug 334464
Copy-paste of calendar events causes Evolution to lock up
Last modified: 2013-09-13 00:47:52 UTC
Copy-paste of calendar events causes Evolution to lock up. This was the case in at least Evo 2.5.90 to 2.5.92. Restarting Evo usually shows the pasted event in the correct place, but you have to kill Evo and restart to actually see it.
cannot reproduce this, how exactly do you copy and paste? which view are you in?
Also, can you provide us with a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance.
Regular calendar day view, create an event called "Test" then right-click on the event and go "Copy", then click elsewhere on the same day and right-click then go "Paste". Locks up 100% of the time. With Evo locked up, attaching gdb gives the following: (gdb) thread apply all bt
+ Trace 67088
Thread 1 (Thread -1208948544 (LWP 7069))
hmm, still cannot reproduce this - today's evo2.5.92cvs-head on suse9.3 here. how do you set up that appointment? directly in the day view by typing, or do you use the appointment editor? could be an e-d-s crash.
# rpm -q evolution evolution-data-server evolution-2.6.0-1 evolution-data-server-1.5.92-1 (from FC5) I set up an appointment by clicking on an empty place on the calendar, then typing. The weird thing is that it says "<signal handler called>" but it's just frozen, no segfault. I don't think I've seen that before... It looks like it's trying to free a null value or something. Yes, looks more like e-d-s.
err.. is it really intended to use a stable evo release (2.6.0) together with an unstable e-d-s release (1.5.92)? this sinÄt good at all, update e-d-s to 1.6.0.
I'm using what has been available in Rawhide for more than a week. There is a mismatch in the version numbers there. I'm assuming that is intentional.
In fact I just checked and FC5 *ships* with the above RPM versions.
The windows clipboard has annoyances also!
Luke: Is this still happening ? I tried on 'Personal', 'Groupwise' and 'Exchange' calendar, it is not reproducible in Evolution 2.6.2.
Without that code being changed, there is absolutely no point in asking if it still happens and setting it to NEEDINFO. Detailed Description given, good stacktrace. REOPENing. (Please don't resort to NEEDINFO'ing bugs, rather than working at the code.)
That said, can't reproduce this issue either. WORKSFORME following the given details.
Yes, I still have 100% reproducibility with: $ rpm -q evolution evolution-data-server evolution-2.6.2-1.fc5.5 evolution-data-server-1.6.2-1.fc5.1 Do you want another stack trace for this version, or is the one above close enough?
I believe I have a solution for this. This same bug is filed downstream in Red Hat's Bugzilla: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167157 This one was a beast to track down, but in e_calendar_view_add_event() we have this logic (slightly reformatted): uid = NULL; if (e_cal_create_object (client, e_cal_component_get_icalcomponent (comp), &uid, NULL)) { if (uid) { e_cal_component_set_uid (comp, uid); g_free (uid); } ... } The string 'uid' is owned by 'client', so we have no business freeing it here. Removing the g_free() call eliminates the crash on paste.
Created attachment 69862 [details] [review] Patch for Evolution 2.7.90
Created attachment 69864 [details] [review] Patch for Evolution 2.6.2
The memory for the uid is owned by the caller. You can see that the uid which is received from e_cal_create_object is not freed in ECal anywhere. The uid has been duped in e-cal.c : cal_object_created_cb and has not been freed anywhere. It is asssigned to the uid passed by the caller at e-cal.c: e_cal_create_object: 4349 if (uid) *uid = our_op->uid; So the caller is responsible for free'ing it. The traces definitely show that there is a crash. Unfortunately, am not able to reproduce the issue.
Chen, thanks for the clarification. I think I have it now. Luke indicated that he's using Fedora, so I had a look at the patches we have downstream. I found that we are still including patches from bug #309079 in evolution-data-server, even though Harish rejected them. In particular, have a look at attachment #48376 [details]. So my patch was simply masking the problem. I didn't realize that ownership of the string is transferred to the caller. This is clearly a downstream bug, so I think this bug can be closed here. Luke, please see [1] for further updates on this issue. [1] http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167157
mbarnes: okay, thanks for the feedback.