On Fri, Aug 8, 2008 at 3:41 PM, manoj manoj
<manoj_karakkat at rediffmail.com>wrote:
> Hi Benny,
>
> The assertion failure is happening in the following function
>
> PJ_DEF(pj_atomic_value_t) pj_atomic_get(pj_atomic_t *atomic_var)
> {
> PJ_CHECK_STACK();
> PJ_ASSERT_RETURN(atomic_var, 0);
>
> return atomic_var->value;
> }
>
> in os_core_win32.c
> And the following is the call stack:
>
> msvcr90d.dll!_wassert(const wchar_t * expr=0x005fc13c, const wchar_t *
> filename=0x005fbcd8, unsigned int lineno=598) Line 335 C
> > TestPJSIP.exe!pj_atomic_get(pj_atomic_t * atomic_var=0x00000000) Line
> 598 + 0x24 bytes C
> TestPJSIP.exe!pjsip_tx_data_dec_ref(pjsip_tx_data * tdata=0x01899fcc)
> Line 350 + 0xf bytes C
> TestPJSIP.exe!tsx_destroy(pjsip_transaction * tsx=0x0188c08c) Line 943 +
> 0xf bytes C
> TestPJSIP.exe!tsx_set_state(pjsip_transaction * tsx=0x0188c08c,
> pjsip_tsx_state_e state=PJSIP_TSX_STATE_DESTROYED, pjsip_event_id_e
> event_src_type=PJSIP_EVENT_TIMER, void * event_src=0x0188c190) Line 1094 +
> 0x9 bytes C
> TestPJSIP.exe!tsx_on_state_terminated(pjsip_transaction * tsx=0x0188c08c,
> pjsip_event * event=0x0112fbb0) Line 2856 + 0x19 bytes C
> TestPJSIP.exe!tsx_timer_callback(pj_timer_heap_t * theap=0x0033c328,
> pj_timer_entry * entry=0x0188c190) Line 1009 + 0x12 bytes C
> TestPJSIP.exe!pj_timer_heap_poll(pj_timer_heap_t * ht=0x0033c328,
> pj_time_val * next_delay=0x0112fdd8) Line 517 + 0x12 bytes C
> TestPJSIP.exe!pjsip_endpt_handle_events2(pjsip_endpoint *
> endpt=0x0033c184, const pj_time_val * max_timeout=0x0112ffa8, unsigned int *
> p_count=0x00000000) Line 665 + 0x10 bytes C
> TestPJSIP.exe!pjsip_endpt_handle_events(pjsip_endpoint *
> endpt=0x0033c184, const pj_time_val * max_timeout=0x0112ffa8) Line 721 +
> 0xf bytes C
> TestPJSIP.exe!CSipClient::SipClientThread(void * __formal=0x00000000)
> Line 107 + 0x13 bytes C++
>
>
It looks like the transaction tries to free up the transmit data (with
pjsip_tx_data_dec_ref()), but this transmit data has been freed before. You
can see the log where this is destroyed in your original log:
16:25:49.781 tdta0126B198 Destroying txdata Response
This shouldn't happen (i.e. the txdata shouldn't be destroyed here), as the
transaction still keeps reference to it.
And the reason why this happens, is because the the txdata reference counter
is wrongly decremented somewhere. And this probably is related to this
error:
16:25:49.672 inv01279A1C SDP negotiation done, status=220049
I tried to reproduce it here by injecting the SDP negotiation error, but
couldn't manage to trigger the same behavior. So I suspect the mistake is in
the application code. Check for anything that calls pjsip_tx_data_dec_ref().
Cheers
Benny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080808/00893d51/attachment.html
