Re: [Evolution-hackers] Evolution-data-server crashes when running syncevolution - poll() called with GPollFD?

[Patrick Ohly <Patrick Ohly gmx de>]

On Thu, 2007-11-01 at 18:45 -0400, Matthew Barnes wrote:
> On Thu, 2007-11-01 at 23:06 +0100, Patrick Ohly wrote:
> > can someone please comment on:
> >          http://bugzilla.gnome.org/show_bug.cgi?id=488881
> > 
> > I got Evolution 2.12.x compiled and can reproduce the problem and look
> > at it in a debugger, but I have no clue about the underlying reason.
> > It's somehow related to having poll() as poll_func in a main loop
> > context.
> 
> poll() isn't the problem, this is:

Right, I got distracted by the "[signal handler called]" inside poll().
Poor excuse, I simply wasn't thinking properly anymore :-/

[...]
> Hope this helps,

Yes, it did - thanks!

>From the issue:

-------------------------------------------------------
Okay, I found the reason. In Evolution 2.12.x the behavior of
e_cal_create_object() for objects with a fixed UID has changed. Previously the
call would fail if the UID was already used and then SyncEvolution falls back
to updating that object, roughly like this:

if(!e_cal_create_object(m_calendar, subcomp, &uid, &gerror) &&
   gerror->domain == E_CALENDAR_ERROR &&
   gerror->code == E_CALENDAR_STATUS_OBJECT_ID_ALREADY_EXISTS) {
   e_cal_modify_object(m_calendar, subcomp, CALOBJ_MOD_ALL, &gerror)
}

This code no longer works because now e_cal_create_object() *removes* the
conflicting UID. Then e_cal_modify_object() crashes because the hash is called
with a NULL UID pointer.

I don't know if this change was intentional; perhaps it was added to allow a
second e_cal_create_object() too succeed. I think it would have been better to
preserve the old behavior and document it. Clients need to decide how to handle
the E_CALENDAR_STATUS_OBJECT_ID_ALREADY_EXISTS error anyway and IMHO updating
instead of duplicating the event is the more useful choice. If the client
wanted to duplicate, it could clear the UID.

Anyway, now that the reason is clear it was easy to add a workaround. Now the
code makes less assumptions about e_cal_create_object() (which is always good)
and restores the UID before e_cal_modify_object(). I'll keep the issue open
until I have a SyncEvolution with the workaround released, then close it.

Thanks to all who helped investigate this and to Matthew Barnes for pointing me
in the right direction on the Evo developer list.
-------------------------------------------------------

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/