[reSIProcate] Query on UPDATE message in Resiprocate ?
Hi,
Has anyone implemented UPDATE method using Resiprocate ? Is
implementing
UPDATE as simple as adding a new message in the Master Profile ? Or will
this be a change in state handling in the dispatch( ) function and a new
call back will have to be written ?
-Regards
Asheesh.
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Justin
Matthews
Sent: Friday, October 21, 2005 11:06 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
> `3/4"-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