pidgin: ebc5ac66: Don't try to tell the IM network that we...

[Mark Doliner]

On Mon, 23 Jun 2008 21:02:28 -0500, Kevin Stange wrote
> Kevin Stange wrote:
> > Stu Tomlinson wrote:
> >> On Fri, 2008-05-02 at 02:20 -0400, markdoliner at pidgin.im wrote:
> >>> -----------------------------------------------------------------
> >>> Revision: ebc5ac66e700f6c67e30069ee2ebd4bb61f82ec8
> >>> Ancestor: 2a2005d1ea7113d6455687048cd66fdb825b991b
> >>> Author: markdoliner at pidgin.im
> >>> Date: 2008-05-02T06:15:33
> >>> Branch: im.pidgin.pidgin
> >>> URL: 
> >>>
http://d.pidgin.im/viewmtn/revision/info/ebc5ac66e700f6c67e30069ee2ebd4bb61f82ec8 
> >>>
> >>>
> >>> Modified files:
> >>>         libpurple/idle.c
> >>>
> >>> ChangeLog:
> >>> Don't try to tell the IM network that we're not idle when we disconnect.
> >>> This was causing a crash for me in silc when I got disconnected while
> >>> idle.  I'm not really sure why we would want to do this... the commit
> >>> message was "A patch from Kevin Stange that should fix some idleness
> >>> problems with MSN and Yahoo" but I couldn't find any more info about
> >>> that.
> >>
> >> Maybe this is what is causing the failure to return from idle reported
> >> to support at pidgin.im ? or maybe it's just uncovered some other
> >> brokenness?
> >>
> > 
> > If it's the cause, how did it not manifest itself for 2 years?  I've 
> > seen the idle issue reported in the mailing list, actually, but I 
> > haven't managed to track it down yet.  It definitely started sometime in 
> > the past couple releases.
> >
> 
> Bah, nevermind me.  I read your explanation backwards.  You're 
> saying this commit from Mark to undo the change did so.  The 
> function being called does that Mark does, except it also unsets the 
> idle on the account itself.  My guess is that the presence has to be 
> removed from the account or when it signs back on, even though it's 
> not in the glist, it still sets itself idle.

Oh I see, that sounds likely.  The silc crash was because
prpl_info->set_idle() was being called with a gc that was disconnecting... I
think maybe gc->proto_data had been free'd already, but gc still existed.  It
didn't seem like something prpls should have to deal with.

I reverted my change to idle.c and instead changed the silc prpls to check for
null before doing stuff.

> The crash in SILC and that are probably signs of brokenness.  We 
> might consider that if the glist is not in fact what the accounts 
> use to determine their idleness, should that glist exist, or should 
> the other place for storing idle be removed instead?
>
> The more places we track one piece of information independently the 
> better the chance for them to get out of sync with one another.


I think we might need to keep "GList *idled_accts" in idle.c.  See the comment
for that variable at the top of idle.c.

-Mark