RE: !Exception in DUM during processing ofDialogSet::End()calledbyclient app REF: RE: [reSIProcate]!Exception in DUMhandlingbogus ACK
I think your fix is correct - setting the mState to Destroying should be done
whenever mDum.destroy(this) is called. I can't figure out why you would be
getting the assert that you mentioned though.
With your change - if you call end() before any response is received then
DialogSet goes to a WaitingToEnd state. The first response processed after
that (ie. the 100) - will cause the DialogSet to send a cancel and set it's
state to Destroying. Once the state is destroying, no other responses should
be processed. How are you getting to line 602 in DialogSet, to create a Dialog?
Scott
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Justin Matthews
> Sent: Monday, October 24, 2005 1:30 PM
> To: 'Resip Devel'
> Subject: RE: !Exception in DUM during processing
> ofDialogSet::End()calledbyclient app REF: RE: [reSIProcate]!Exception in
> DUMhandlingbogus ACK
>
> Actually, the following assertion is failing.
>
>
> Dialog.cxx:171
>
> BaseCreator* creator = mDialogSet.getCreator();
> assert(creator);// !jf! throw or something here
>
> This is being called from DialogSet.cxx:602.
>
>
> Looks like there is more work to be done here for this scenario. The
> dialog
> should never be created because the dialog set is in the Destroying state.
> What is the best way to handle this?
>
> Thanks,
>
> -Justin
>
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Justin
> Matthews
> Sent: Monday, October 24, 2005 12:29 PM
> To: 'Resip Devel'
> Subject: RE: !Exception in DUM during processing of
> DialogSet::End()calledbyclient app REF: RE: [reSIProcate] !Exception in
> DUMhandlingbogus ACK
>
> The following change has so far fixed the crash described below.
>
> Could someone please verify this fix and make the modification to the
> repository?
>
> DialogSet.cxx:707
>
> if (mDialogs.empty())
> {
> // !jf! if 200/INV crosses a CANCEL that was sent after
> receiving
> // non-dialog creating provisional (e.g. 100), then we need
> to:
> // Add a new state, if we receive a 200/INV in this state, ACK
> and
> // then send a BYE and destroy the dialogset.
> /* keeping mState active may allow processing of messages
> * before this object is completely destroyed */
> mState = Destroying;
> mDum.destroy(this);
> }
>
> Thanks,
>
> -Justin
>
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Justin
> Matthews
> Sent: Friday, October 21, 2005 1:46 PM
> To: 'Resip Devel'
> Subject: RE: !Exception in DUM during processing of DialogSet::End()
> calledbyclient app REF: RE: [reSIProcate] !Exception in DUM handlingbogus
> ACK
>
> Also, I added the following trace lines to aid in the debugging. It would
> be
> nice to keep them around. Could someone add these to the code base?
>
> Dialogusagemanager.cxx:901
>
> InfoLog(<< "DUM::destroy, posting DestroyUsage DialogSet * : " << std::hex
> << dset << ", Id: " << dset->getId() );
>
> Destroyusage.cxx:79
>
> InfoLog(<< "DestroyUsage::destroy(), Deleting mDialogSet: " << std::hex <<
> mDialogSet << ", id: " << mDialogSet->getId());
>
> Thanks,
> -Justin
>
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Justin
> Matthews
> Sent: Friday, October 21, 2005 1:36 PM
> To: 'Resip Devel'
> Subject: !Exception in DUM during processing of DialogSet::End() called
> byclient app REF: RE: [reSIProcate] !Exception in DUM handling bogus ACK
>
> Hello,
>
> Similar to the reference issue posted below, I believe there is another
> scenario creating an exception during destruction of a dialogset. The
> relevant log file can be made available if further information is
> necessary.
>
> The short summary is that my app sends an invite request using DUM and a
> short time after calls DialogSet::end(). The problem arises when the 100,
> 180 and 200 responses are received after my end() call and are still
> processed.
>
> 10:44:23.609 [2252] Invite created
>
> 10:44:26.562 [2588] 100, 180 and 200 are received from wire
>
> 10:44:26.875 [2252] DialogSet::end() called
>
> 10:44:27.078 [2252] processResponse (100)
>
> 10:44:27.093 [2252] Create CANCEL, post(DestroyUsage(dialogset))
>
> 10:44:27.109 [2252] processResponse (180)
>
> 10:44:27.109 [2252] processResponse (200)
>
> 10:44:27.125 [2252] !!! Creates a new dialog here !!!
>
> ...
>
> 10:44:28.265 [2252] Finally get around to deleting the dialog set from
> original post(DestroyUsage(dialogset)) (destroyusage.cxx:79)
>
> In the destructor of the dialogset, delete any remaining dialogs (now
> there
> is a new dialog (from time 27.125). In the dialog destructor erase the
> dialog from the dialog set, call dialogset.possiblydie. In
> DialogSet::possiblyDie(), mDialogs is empty and the state is not
> Destroying,
> so post another DestroyUsage!!!
>
> I am not sure I have any valid suggestions on fixing this, I haven't
> looked
> into it enough and am sure that any changes made would affect other parts
> of
> the DUM adversely. The only suggestion is to possibly set mState to
> destroying in DialogSet::end(), line 707 ???
>
> Thanks,
>
> -Justin
>
>
>
>
> -----Original Message-----
> From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
> Sent: Tuesday, July 05, 2005 8:31 AM
> To: 'Derek MacDonald'; Scott Godin; jason@xxxxxx; 'david Butcher'
> Cc: justin.matthews@xxxxxxx
> Subject: RE: [reSIProcate] !Exception in DUM handling bogus ACK
>
> After a bit more thought - I realize that if we do this, then there is a
> slight possibility that we can have a memory leak. Take the following
> scenario - DestroyUsage is queued to destroy a dialogset and we remove the
> entry from the map, then DialogUsageManager is destructed - since the
> DialogSet is gone from the map it will not properly deleted. Do you think
> this is worth worrying about?
>
> If so, I think we should go with a solution that is similar to Justin's
> proposed solution. Ie. Set a flag in the Dialog/DialogSet when the
> DestroyUsage message is posted. Check this flag in findDialogSet and
> findDialog, and return as if Dialog/DialogSet does not exist if it is in
> the
> middle of "destroying".
>
> I'm leaning towards the former - but it will involve an extra check in
> each
> findDialog/findDialogSet calls - sound good?
>
> Scott
>
> -----Original Message-----
> From: Derek MacDonald [mailto:derek@xxxxxxxx]
> Sent: Monday, July 04, 2005 4:52 PM
> To: 'Scott Godin'; jason@xxxxxx; 'david Butcher'
> Cc: justin.matthews@xxxxxxx
> Subject: RE: [reSIProcate] !Exception in DUM handling bogus ACK
>
> It seems to me that findDialog should fail; callbacks on a destroyed
> dialog
> could be confusing. It sounds like your better solution is a way of
> realizing this behaviour; is this true?
>
> --Derek
>
> CONFIDENTIALITY NOTICE
>
> This email and any files transmitted with it contains proprietary
> information and, unless expressly stated otherwise, all contents and
> attachments are confidential. This email is intended for the addressee(s)
> only and access by anyone else is unauthorized. If you are not an
> addressee,
> any disclosure, distribution, printing or copying of the contents of this
> email or its attachments, or any action taken in reliance on it, is
> unauthorized and may be unlawful. If you are not an addressee, please
> inform
> the sender immediately and then delete this email and any copies of it.
> Thank you for your co-operation.
>
>
> > -----Original Message-----
> > From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
> > Sent: Monday, July 04, 2005 1:11 PM
> > To: 'jason@xxxxxx'; 'Derek MacDonald'; 'david Butcher'
> > Cc: 'justin.matthews@xxxxxxx'
> > Subject: FW: [reSIProcate] !Exception in DUM handling bogus ACK
> >
> > Essentially we are getting a new message in a Dialog that is in the
> middle
> > of being destroyed. The problem stems from the fact that it takes 3
> > process
> > loop iterations to entirely destroy an invite session / dialog and
> dialog
> > set.
> >
> > Ie. findDialog or findDialogSet can return a dialog that has already
> > posted
> > to be destroyed.
> >
> > Do you think Justin's solution is good enough? It seems to me there
> could
> > issues in other area's as well (ie. Dialogs). What do you think the
> > intended behavior should be? If a dialog is in the middle of being
> > destroyed should the find fail?
> >
> > Maybe a better solution would be to move (or copy) the
> > mDum.removeDialogSet(this->getId()) call from the DialogSet destructor
> to
> > the possiblyDie() function when mDum.destroy(this) is called.
> >
> > Opinions?
> >
> > Scott
> >
> > -----Original Message-----
> > From: Justin Matthews [mailto:justin.matthews@xxxxxxx]
> > Sent: Thursday, June 30, 2005 9:14 AM
> > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: [reSIProcate] !Exception in DUM handling bogus ACK
> >
> > Hello,
> >
> > I believe that the following scenario is causing the DUM to raise a
> fatal
> > exception. A log file is attached that also shows this scenario (may be
> > easier to decipher than my description).
> >
> > To start this scenario a BYE is received for a Dialog and the proper
> 200OK
> > is sent to the UAC. The processing then continues as follows:
> >
> > [2588] [DialogUsageManager. 840] [Got: DestroyUsage INVITE:
> >
> > (call destroy() which calls delete)
> >
> > [2588] [InviteSession. 51] [^^^ InviteSession::~InviteSession
> >
> > (At this point in ~InviteSession() mDialog.mInviteSession is set to 0)
> > (In ~DialogUsage()
> > call mDialog.possiblyDie()
> > call mDum.Destroy(this)
> > post(DestroyUsage(dialog))
> >
> > [ 944] [DEBUG] [Transport. 210] [incoming from:
> >
> > (At this point there is a context switch to another thread)
> > (an ACK is received and sent to the TU)
> >
> > [2588] [DialogUsageManager. 840] [Got: DestroyDialog
> > (switching back to the DUM thread, delete the dialog from the BYE)
> > (call destroy(), which calls delete)
> >
> > [2588] [Dialog. 211] [Dialog::~Dialog() ]
> > (call mDialogSet->possiblyDie()
> > call mDum->post(DestroyUsage(dialogset))
> >
> > [2588] [DialogUsageManager.1222] [DialogUsageManager::processRequest:
> > (handle the ACK, NOTE! This is happening after the dialogset has been
> set
> > to
> > die)
> >
> > [2588] [DialogSet. 663] [findDialog:
> > [2588] [DialogSet. 598] [Creating a new Dialog from msg:
> >
> > [2588] [Dialog. 347] [Drop stray ACK or CANCEL
> > (drop the ACK because mInviteSession in the dialog is NULL)
> >
> > [2588] [DialogUsageManager. 840] [Got: DestroyDialogSet
> > (finally received the destroy dialog message from the original BYE)
> >
> > (call destroyUsage->destroy(), delete mdialogSet)
> > (The destructor of mDialogSet will iterate through all remaining
> Dialog's
> > and delete them, !NOTE! there is now a new Dialog in the dialogSet from
> > the
> > incoming ACK! Deleting this new dialog will then cause another
> > mDialogSet.possiblyDie() from the Dialog destructor. This will then
> cause
> > another DestroyUsage message posted back to the DUM fifo:
> >
> > [2588] [INFO ] [DialogUsageManager. 840] [Got: DestroyDialogSet
> > `¾"-63439337-000e-Call7-f9346b6c]
> > [2588] [INFO ] [DialogUsageManager . 944] [Destroying usage]
> > [ 944] [FATAL] [ExceptionFilter . 46]
> >
> >
> > The exception is occurring in the sipstack thread (944) and from my
> > analysis
> > of the crash information this is most likely caused by corrupted memory.
> >
> > I am testing a quick fix by adding a flag that the dialogset has been
> > posted
> > for destruction and adding the following check:
> >
> > DialogUsageManager.1259 (DUM::processRequest())
> > if (ds == 0 || true == ds->markedForDestruction_)
> > {
> >
> > Thanks,
> >
> > Justin
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel