GNOME Bugzilla – Bug 579176
crashes when accepting meeting invitation
Last modified: 2009-05-19 12:40:57 UTC
the bug has been opened on https://bugs.launchpad.net/bugs/357636 "While processing a repetitive meeting request evolution (2.26.0-0ubuntu2) crashes when opening the message. Only selecting this mail to read crashes evolution with a message in the progress bar on the bottom saying, (translated from Portuguese) "Parsing Message". I don't know if it helps, but the mail is from a POP3 mail server. http://launchpadlibrarian.net/25011541/ProgressMeeting.calendar Webmail text download of the received meeting mail (1.4 KiB, text/plain)
+ Trace 214517
Created attachment 132771 [details] [review] proposed eds patch for evolution-data-server; Detached instances don't have a master object.
there is an ubuntu bug submitter confirming that the change fixes the issue
there is a bug submitter getting an another crasher after this change http://launchpadlibrarian.net/25917087/EDS_Backtrace.txt
Please commit the patch to trunk and stable branch.
Looking at trace at comment #3, the similar check for the presence of master instance should be put in at remove_instance also. Probably milan can make this change too while committing the patch.
Created attachment 133404 [details] [review] proposed eds patch ][ for evolution-data-server; The extended patch is quite bigger, thus rather resending here. Moreover, if I got it right, then for example removal of a detached instance is not notified, when the full_object is NULL. Am I right? If so, then that can be a bug, right?
Both removal and modifications should be notified even for detached instances. They need to be handled like non-recurring appointments in case of modifications and deletions.
Rest of the patch looks fine.
Strange, I tried and I cannot see a difference. How do I recognize the fault?
There will be no difference if you decline the meeting in the mailer and then go to calendar component as a refresh in view happens naturally. But if the instance is deleted/modified from the calendar view, there would be a difference as the view needs notification for showing the changes made.
I did delete the meeting in the calendar component. Both detached instance, and then the master object too. It worked.
Got it. ECalBackendSync (_e_cal_backend_remove_object) handles it internally for those cases. notify_changes is used when calendar is reloaded which is not used at the moment. When someone starts using e_cal_backend_file_reload, they would notice the difference.
Chen, aha, OK, I believe it's out of scope of this bug. Could we close this crasher (commit the patch) and take care of the other brokeness anywhere else?
sure, I had to put this in as this patch introduces it. Probably you can remove the changes made in notify_*_cb and commit the other parts.
Created commit 29c6fd1 in master. (Slightly modified above patch, with removed notify_*_cb chunks.