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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
