[Adium-devl] Thursday! Thursday! Thursday!

[Evan Schoenberg]

On Jan 17, 2007, at 4:10 AM, Elliott Harris wrote:

> I'm dedicating this Thursday, January 18th, 2007, official kill-the-
> upnp-bug-day. I'm going to sit down for a good 9 hours and attempt to
> build debug information and hopefully fix the upnp bug.
Fantastic!  I hope the hunt goes so well that a day of hacking  
resolves other bugs, as well - but even if it doesn't, that's a big  
one which knocks out a lot of folk, and it'll be great to have it  
squelched :)

> I am writing
> this to solicit some company for some, if not all of the day in
> attempting to put our shiny new debug messages to work, and hopefully
> devising a fix for the bug.
I'll be in class 8 AM to 5 PM; I'll try to be around after that :)

> e should be able to troubleshoot some on our own to put
> those debugging messages to work, and may be able to solicit some
> more help from IRC to further our efforts. I think if we sit down and
> put a solid day of work on it, it shouldn't be too bad.
I've added a bit more debug logging to libgaim in util.c. There's a  
crash after a gaim_util_fetch_url_request() process fails which is  
oddly similar to the upnp crash.. and upnp does utilize  
gaim_util_fetch_url_request() .  Our previous thought had been that  
the UPnPMappingAddRemove object (ar) was being released  
prematurely... logging I've gotten from a user doesn't show that,  
though -- the log ends like this:
----
19:10:48: (Libgaim: upnp) done_port_mapping_cb(): Failed HTTP_OK

19:10:48: (Libgaim: upnp) done_port_mapping_cb(success == 0): Calling  
cb for a23ded0
19:10:48: (Libgaim: network) Couldn't create UPnP mapping
<<CRASH>>
----
with no previous logging of "a23ded0", the UPnPMappingAddRemove  
object which was passed to done_port_mapping_cb().  Now, creation of  
UPnPMappingAddRemove objects isn't being logged; that might be worth  
adding, as one possibility which occured to me earlier is that it's  
not the ar being released but rather that somewhere higher up the  
chain -- say, in the utl_fetch_url_request() stuff -- there's a  
release, which leads to a completely invalid pointer being passed to  
done_port_mapping_cb(), one which never was a UPnPMappingAddRemove.

The new logging will therefore show when gaim_util_fetch_url_cancel()  
is called, which is the only way that GaimUtilFetchUrlData objects  
are freed.

I hope that helps get a start on a fresh direction to investigate!

-Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070117/01ee06f3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070117/01ee06f3/attachment.sig>