pidgin: ebc5ac66: Don't try to tell the IM network that we...
mark at kingant.net
Wed Jun 25 20:03:47 EDT 2008
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:
> >>> 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.
More information about the Devel