[asterisk-dev] [svn-commits] murf: branch murf/bug11210 r93624 - /team/murf/bug11210/channels/chan_sip.c

[Steve Murphy]

On Tue, 2007-12-18 at 17:56 +0100, Johansson Olle E wrote:
> 18 dec 2007 kl. 17.01 skrev SVN commits to the Digium repositories:
> 
> > Author: murf
> > Date: Tue Dec 18 10:01:43 2007
> > New Revision: 93624
> >
> > URL: http://svn.digium.com/view/asterisk?view=rev&rev=93624
> > Log:
> > I added dialog_ref() and dialog_unref() calls in the dialog waitid  
> > ast_sched_xxx calls. It seems to me disturbing if a dialog were to  
> > disappear while a sched event was still waiting to happen. Probably  
> > wouldn't normally happen anyway, but just in case....  Also, was  
> > previously suffering from lockups in the unload_module stuff, but  
> > maybe the previous fixes concerning dialog callid changes might have  
> > also cleared up this problem as well. Will leave the debugs in place  
> > until I'm more sure.
> But if the dialog disappears we cancel the scheduled events. That's  
> happening early in the _destroy function, right?

That's a good point. I'll review the whole process again. 

If my thinking on this aspect is a little muddled, I blame it on the
original 
state of the code: the __sip_destroy frees up the object, but was being
called directly in a few places. An object's destructor probably had
best not destroy/unlink-itself-from  the objects that contain pointers
to itself. It leads to a situation where the refcount for a dialog never
gets to zero, because the destructor removes the last references...  so
I've been splitting __sip_destroy into an "unlink_all" routine that is
meant to unref the object, and the destroy func that just frees up the
object. Doing the right things in the correct routine is the trick.

I've invested a lot of work in making sure the refcounted objects
actually get
destroyed when they should; that **all** refcounted objects get
destroyed when
you do a "stop gracefully", etc. This kind of activity is hard to track,
and has cost me a lot of work to monitor it;  and that work will most
likely get tossed before I can commit the code.


murf


-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3239 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20071220/555cf22a/attachment-0001.bin