im.pidgin.pidgin: d77adf1b9a4b44f121620f20e2643602e3f6776e

Mark Doliner mark at kingant.net
Tue Jan 22 20:45:57 EST 2008


(resending this because it didn't go through the first time, apologies to Evan
for him getting two copies of it)

On Sun, 20 Jan 2008 15:55:54 -0500 (EST), evands wrote
> -----------------------------------------------------------------
> Revision: d77adf1b9a4b44f121620f20e2643602e3f6776e
> Ancestor: 2276e6d6441284f869c0182cba84053a7e861d23
> Author: evands at pidgin.im
> Date: 2008-01-20T20:52:45
> Branch: im.pidgin.pidgin
> 
> Modified files:
>         libpurple/protocols/oscar/flap_connection.c
> 
> ChangeLog:
> 
> Track validity of flap_connections to prevent a crash when a 
> disconnect is initiated via purple_timeout_add in 
> flap_connection_schedule_destroy() and then is subsequently 
> destroyed before the timeout is actually called.

I disapproved this.  I guess there are two reasons:

1. Checking the validity of a FlapConnection by checking whether the memory
address of the struct exists in a GList is ugly.  I imagine it will work
99.99999999% of the time, but it is theoretically possible for the same memory
address to be reused for a new and different FlapConnection, which means you
would end up free'ing something you hadn't intended.

2. This totally should not be necessary.  If the FlapConnection is destroyed
by flap_connection_destroy before the timeout is called then the timeout is
removed.  See the first two lines of flap_connection_destroy().

If you can provide me a back trace and maybe a way to reproduce the crash I'll
gladly try to find the real cause.

For the record I absolutely hate PURPLE_CONNECTION_IS_VALID and think we
should get rid of it.

-Mark 




More information about the Devel mailing list