Hi Benny,
I commented out the pjsip_endpt_schedule_timer caller line and since
then I haven't got any assertion.
I even tested it with three times bigger traffic but no problem.
Cheers,
Gergo
--
Gergely Kovacs
http://www.iptel.org/~gergo
Benny Prijono wrote:
> Hi Gergo,
>
> just a quick check first. If you disable the call_duration timer
> altogether (by commenting out the call to schedule_timer) and rely on
> the UAS disconnecting the call, do you still get the assertion?
>
> Sorry but I couldn't reproduce this on my machine for some reason.
>
> cheers,
> -benny
>
> On 3/5/08, Gergely Kovacs <gergo at iptel.org> wrote:
>
>> Hi Benny,
>>
>> Thank you the answer! I did the modifications you had suggested, but it
>> seems as if it'd just produce different asserts:
>>
>> stx: ../src/pjsip/sip_transaction.c:2792:
>> tsx_on_state_completed_uac: Assertion `event->body.timer.entry ==
>> &tsx->timeout_timer' failed.
>> stx: ../src/pj/timer.c:329: cancel: Assertion `entry ==
>> ht->heap[timer_node_slot]' failed.
>>
>>
>>
>> I did these changes:
>>
>> static void call_duration_callback(pj_timer_heap_t
>> *timer_heap,
>> struct pj_timer_entry
>> *entry)
>> {
>> pj_status_t status;
>> pjsip_tx_data *tdata;
>> pjsip_inv_session *inv;
>>
>>
>> PJ_UNUSED_ARG(timer_heap);
>> if (entry->user_data == (void*)STX_INVALID_ID) {
>> PJ_LOG(1,(THIS_FILE, "Invalid call ID in timer callback"));
>> return;
>> }
>>
>> inv = get_inv_call(entry->user_data);
>>
>> status = pjsip_inv_end_session(inv, PJSIP_SC_OK, NULL, &tdata);
>> if (status == PJ_SUCCESS && tdata)
>> status = pjsip_inv_send_msg(inv, tdata);
>>
>> {
>> call_data *this_call = (call_data*)inv->mod_data[0];
>> this_call->timer.id = 0;
>> }
>> release_call(entry->user_data);
>> }
>>
>>
>>
>> static void call_on_state_changed(pjsip_inv_session *inv,
>> pjsip_event *e)
>> {
>> call_data *this_call = (call_data*)inv->mod_data[0];
>> PJ_UNUSED_ARG(e);
>>
>> /* Bail out if this is not an outgoing call */
>> if (inv->role != PJSIP_UAC_ROLE)
>> return;
>>
>> if (inv->state == PJSIP_INV_STATE_CONFIRMED) {
>> pjsip_tx_data *tdata;
>> pj_status_t status;
>> /* Schedule timer to hangup call after the specified duration */
>> pj_time_val delay;
>>
>> if (app.client.rnd_call_len) {
>> delay.sec = app.client.call_len + RND(app.client.rnd_call_len);
>> } else
>> delay.sec = app.client.call_len;
>>
>> if (delay.sec) {
>> delay.msec = 0;
>>
>> pj_bzero(&this_call->timer, sizeof(this_call->timer));
>> pj_timer_entry_init(&this_call->timer, 1,
>> this_call, &call_duration_callback);
>> pjsip_endpt_schedule_timer(app.sip_endpt, &this_call->timer,
>> &delay);
>> } else {
>> status = pjsip_inv_end_session(inv, PJSIP_SC_OK, NULL, &tdata);
>> if (status == PJ_SUCCESS && tdata)
>> status = pjsip_inv_send_msg(inv, tdata);
>> release_call(this_call);
>> }
>> } else if (inv->state == PJSIP_INV_STATE_DISCONNECTED) {
>> report_completion(inv->cause, &inv->cause_text);
>> inv->mod_data[mod_responder.id] = (void*)1;
>> if (this_call->timer.id != 0) {
>> pjsip_endpt_cancel_timer(app.sip_endpt, &this_call->timer);
>> }
>> }
>> }
>>
>>
>> --
>> Gergely Kovacs
>>
>> http://www.iptel.org/~gergo
>>
>>
>>
>>
>> Benny Prijono wrote:
>> On 2/29/08, Gergely Kovacs <gergo at iptel.org> wrote:
>>
>>
>> Hi Benny,
>>
>> It is a SIP UA application for Linux based on pjsip-perf. Maybe I use some
>> PJSIP schedule function wrong. I enclosed the souce.
>>
>> I've met two other asserts since the last post:
>> ../src/pj/timer.c:329: cancel: Assertion `entry ==
>> ht->heap[timer_node_slot]' failed.
>> ../src/pjsip/sip_transaction.c:2792:
>> tsx_on_state_completed_uac: Assertion `event->body.timer.entry ==
>> &tsx->timeout_timer' failed.
>>
>>
>> I used SIPp as UAS and I reproduced the failure with these switches:
>>
>> ./stx -t sip:uaa2 at domain.com -o "sip:127.0.0.1;lr" -f sip:uaa1 at domain.com
>> -p 5080 -c 3000 -w 50 --call-len=15 --rnd-call-len=15 --thread-count=4
>>
>> A pjsip_endpt_handle_events2 was called at stx.c:1450 when the failures
>> occurred.
>>
>>
>> Hi Gergo,
>>
>> it's a bit difficult to find out what's wrong, but my guess is it's
>> caused by the call duration timer not being canceled when the call
>> gets disconnected because of incoming BYE. Perhaps you should add this
>> in call_on_state_changed() callback, when the call state is
>> PJSIP_INV_STATE_DISCONNECTED:
>>
>> if (this_call->timer.id != 0) {
>> pjsip_endpt_cancel_timer(app.sip_endpt, &this_call->timer)
>> }
>>
>> And in call_duration_callback():
>>
>> call_data *this_call = (call_data*)inv->mod_data[0];
>> this_call->timer.id = 0;
>>
>>
>> cheers,
>> -benny
>>
>>
>>
>>
>> Cheers:
>> Gergo
>>
>> --
>> Gergely Kovacs
>> http://www.iptel.org/~gergo
>>
>>
>>
>>
>> Benny Prijono wrote:
>> On 2/26/08, Gergely Kovacs <gergo at iptel.org> wrote:
>>
>>
>> Hi,
>>
>> I developed an User Agent application based on pjsip-perf.c. If I use it
>> as UAC, with thread-count > 1 and there are approximately more than 1000
>> calls waiting to be finished (at the end of client_thread() function),
>> then it will segmentation fault. I use the latest SVN version of PJSIP.
>>
>>
>> Hi Gergo,
>>
>> Thanks for the report. Can you tell me what you have in config_site.h,
>> and the command line options to invoke pjsip-perf?
>>
>> cheers,
>> -benny
>>
>>
>>
>>
>>
>> Here's the backtrace:
>>
>> #0 0x080cd05f in pop_freelist (ht=0x810365c) at ../src/pj/timer.c:136
>> #1 0x080cd6c3 in schedule_entry (ht=0x810365c, entry=0x8630150,
>> future_time=0xa7bcd1fc) at ../src/pj/timer.c:300
>> #2 0x080cdb81 in pj_timer_heap_schedule (ht=0x810365c, entry=0x8630150,
>> delay=0x80f1b28) at ../src/pj/timer.c:472
>> #3 0x080606c6 in pjsip_endpt_schedule_timer (endpt=0x8103474,
>> entry=0x8630150, delay=0x80f1b28) at ../src/pjsip/sip_endpoint.c:733
>> #4 0x08072978 in tsx_on_state_null (tsx=0x8630064, event=0xa7bcd284) at
>> ../src/pjsip/sip_transaction.c:2013
>> #5 0x080719b8 in pjsip_tsx_send_msg (tsx=0x8630064, tdata=0x88d12fc) at
>> ../src/pjsip/sip_transaction.c:1528
>> #6 0x0807688b in pjsip_dlg_send_request (dlg=0x84d346c,
>> tdata=0x88d12fc, mod_data_id=5, mod_data=0x87a9ffc) at
>> ../src/pjsip/sip_dialog.c:1139
>> #7 0x08050f5f in pjsip_inv_send_msg (inv=0x84d3a6c, tdata=0x88d12fc) at
>> ../src/pjsip-ua/sip_inv.c:2078
>> #8 0x0804b838 in call_duration_callback (timer_heap=0x810365c,
>> entry=0x80fb9a0) at stx.c:922
>> #9 0x080cdd38 in pj_timer_heap_poll (ht=0x810365c,
>> next_delay=0xa7bcd3a4) at ../src/pj/timer.c:518
>> #10 0x08060560 in pjsip_endpt_handle_events2 (endpt=0x8103474,
>> max_timeout=0xa7bcd3e0, p_count=0xa7bcd3dc) at
>> ../src/pjsip/sip_endpoint.c:665
>> #11 0x0804c99d in client_thread (arg=0x0) at stx.c:1461
>>
>> (gdb) frame 0
>> #0 0x080cd05f in pop_freelist (ht=0x810365c) at ../src/pj/timer.c:136
>> 136 ht->timer_ids_freelist =
>> (gdb) l
>> 131
>> 132 PJ_CHECK_STACK();
>> 133
>> 134 // The freelist values in the <timer_ids_> are negative, so
>> we need
>> 135 // to negate them to get the next freelist "pointer."
>> 136 ht->timer_ids_freelist =
>> 137 -ht->timer_ids[ht->timer_ids_freelist];
>> 138
>> 139 return new_id;
>> 140
>> (gdb) p ht->timer_ids[ht->timer_ids_freelist]
>> Cannot access memory at address 0xa8c5901c
>> (gdb) p ht->timer_ids_freelist
>> $1 = 4325376
>>
>> I can reproduce it any time.
>>
>> Cheers:
>> Gergo
>>
>> --
>> Gergely Kovacs
>> http://www.iptel.org/~gergo
>>
>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080311/3f82e50d/attachment-0001.html
