| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
It’s possible you’ve exposed a race condition by
using the debugger – I can’t think of what it would be offhand
though. : ( The Debug log should provide more insight. Scott From: Aron Rosenberg
[mailto:arosenberg@xxxxxxxxxxxxxx] One thing that might be going on is that when I sit in a
breakpoint, a 408 transaction is created by the resip stack because of the
“timeout”. Could this because the reason for the crash, onRemoved
gets called, but a 408 is still active… -Aron From: Scott Godin
[mailto:slgodin@xxxxxxxxxxxx] Are you calling all DUM API’s from the same thread
(including the process loop)? From: Aron Rosenberg
[mailto:arosenberg@xxxxxxxxxxxxxx] DUM controls everything. This crash only happens if I have hit a
breakpoint and let it sit for a couple seconds before continuing. For example,
If I have a breakpoint in the onTerminated or onRequestRetry for
ClientSubscriptionHandler implementation. It will crash after the continue.
This never happens except in debug mode and only if breakpoints were used on
the resiprocate thread. -Aron From: Scott Godin
[mailto:slgodin@xxxxxxxxxxxx] If the DialogSet is still around the AppDialogSet should also be
around. Are you deleting your AppDialogSet instances or letting DUM
control their lifetime? Scott From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Aron
Rosenberg So
I have been debugging some resip issues with ClientSubscriptions and keep
getting a NULL pointer crash after I have been sitting at some breakpoints in
the code. The crash occurs in: DialogSet.cxx
line 775 DebugLog ( <<
"### Calling CreateAppDialog ###: " << std::endl <<
std::endl <<msg); ---> AppDialog* appDialog =
mAppDialogSet->createAppDialog(msg); dialog->mAppDialog
= appDialog; appDialog->mDialog
= dialog;
dialog->dispatch(msg); mAppDialogSet
is NULL. The call stack for this crash is as follows: >
resip::DialogSet::dispatch(const resip::SipMessage & msg={...}) Line
775 + 0x1c C++
resip::DialogUsageManager::processRequest(const resip::SipMessage &
request={...}) Line 1560 C++
resip::DialogUsageManager::incomingProcess(std::auto_ptr<resip::Message>
msg={...}) Line 1281 C++
resip::DialogUsageManager::internalProcess(std::auto_ptr<resip::Message>
msg={...}) Line 1134 C++
resip::DialogUsageManager::process() Line 1300 + 0x49 C++
SipEP::run() Line 2404 + 0xb C++ // Is our thread
loop mState
== Established msg
is a NOTIFY The
crash happens after I have requested the ->end() of the ClientSubscription
and a NOTIFY comes in from the wire and I call rejectUpdate(404) since the user
has “ended” the Client Subscription. Then I usually get a call to
onRequestRetry where we return 0. The crash generally occurs after that. I will
try to get a resip debug log up to the crash. Does
this appear to be a resip issue or are we improperly implementing our own
AppDialog and AppDialogSet instances. -Aron --------------------------------------------- Aron
Rosenberg Founder
and CTO SightSpeed
- http://www.sightspeed.com/ 918
Parker St, Suite A14 Berkeley,
CA 94710 Email:
arosenberg@xxxxxxxxxxxxxx Phone:
510-665-2920 Cell:
510-847-7389 Fax:
510-649-9569 SightSpeed
Video Link: http://aron.sightspeed.com |