Re: [reSIProcate] assertion: "DUM let me send a BYE at an incorrectstate"

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

If I'm reading this correctly I think you might be using DUM in an unsupported way.  (Almost)  All calls to DUM methods (including end())  MUST occur from the DUM processing thread.

More information is here.  You can use the methods described in the link to post messages to the DUM thread for legal calls.

http://resiprocate.org/DUM_Threading#Tips_on_Making_Thread_Safe_Calls_when_using_DUM

Scott

On Wed, Feb 24, 2016 at 1:24 PM, Diego Carvalho Domingos <ddomingos@xxxxxxxxxxxxxxx> wrote:

Hi all,

I’m reopening this topic because I think it is not totally fixed. I had the exact same problem due to thread concurrency.
So, the original fix was:

if(!isTerminated())   // make sure application didn't call end()

{

      dispatchConnected(msg);  // act as if we received message in Connected state

}

else

{

      dispatchTerminated(msg);

}

 

But imagine that the application did not call end() from onOfferRequestRejected but pushed an event for another thread (in my case I call it CallManager). In this case, the !isTerminated test will pass and dispatchConnected will be executed. Inside this method, there is this code:

case OnInviteReliableOffer:

*mLastRemoteSessionModification = msg;

transition(ReceivedReinvite);

 

If the context switches to the other thread before transition(ReceivedReinvite) and my CallManager thread sends a BYE (calls end()), the code would end up in the same situation when receiving the 200-OK for the BYE and would crash (assert(0)).
I don’t know what would be the final solution for this since I don’t know much of resiprocate code. Does anyone have a solution for this? Thanks in advance.

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel