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
>
>
