[Adium-devl] Thursday! Thursday! Thursday!

[Elliott Harris]

Evan and Team,

In regards to "a23ded0" every time done_port_mapping_cb() is called,  
a new UPnPMappingAddRemove pointer is created and references whatever  
is passed into done_port_mapping_cb(). The debugging statement  
currently logs the address of this pointer, which will in fact change  
each time, and will indeed not show up previous to it being created a  
couple of lines before the debugging statement.

I'm going to change it to give us the address of the actual  
UPnPAddRemove object and see if it is indeed being destroyed  
prematurely by the error handling code, which is certainly a  
possibility since it isn't crashing on success. Maybe the cleanup  
code is getting called early?

More as it develops.

Elliott

On Jan 17, 2007, at 4:55 PM, Evan Schoenberg wrote:

>
> 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
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070118/380555f3/attachment-0001.html>