Re: [pjsip] Segfault in timer.c
Hi Ming,
I meet a few crash(include this crash stack) in my project. But finally the root cause for these issues(crash) all is the wrong application level logic from the developer, such memory release.
So I suggest pjsip-developer need support better UNIT TEST for timer module to make sure it work well, such as concurrency test. User's application issue thould be checked by users-self.
发件人：pjsip-request pjsip-request@lists.pjsip.org
发送时间：2019年6月1日(星期六) 00:01
收件人：pjsip pjsip@lists.pjsip.org
主 题：pjsip Digest, Vol 141, Issue 22
Send pjsip mailing list submissions to
pjsip@lists.pjsip.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
or, via email, send a message with subject or body 'help' to
pjsip-request@lists.pjsip.org
You can reach the person managing the list at
pjsip-owner@lists.pjsip.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of pjsip digest..."
Today's Topics:
- Re: Segfault in timer.c (Ming)
- Crash when adding a video to the call (with ICE)
(Janusz Kolarczyk) - Re: Crash when adding a video to the call (with ICE) (Ming)
- Re: Crash when adding a video to the call (with ICE)
(Janusz Kolarczyk) - Re: Crash when adding a video to the call (with ICE)
(Janusz Kolarczyk) - Re: Fixed dialog memory leak when no SDP in incoming INVITE
(mscdexdotexe) - vqrd, a vqrtcpxr collector server; lazy implementation of
rfc6035 (jrun)
Message: 1
Date: Fri, 31 May 2019 13:13:08 +0800
From: Ming ming@teluu.com
To: pjsip list pjsip@lists.pjsip.org
Subject: Re: [pjsip] Segfault in timer.c
Message-ID:
CAPimFqC-m4rAChJHX3TaMKR62QCYUZzyu0-OrL+7_OnM_BUCew@mail.gmail.com
Content-Type: text/plain; charset="utf-8"
Hi Ross,
I'm afraid the backtrace alone is not sufficient to pinpoint the cause. We
know that the current timer implementation is not easy to troubleshoot, and
we're thinking of changing it, but for now in order to investigate the
issue further, we will need to get additional information which I mentioned
in the previous email, such as the steps to reproduce, and/or the complete
PJSIP logs level 6 compiled with the timer debugging on.
And I don't think adding locks can help here, because it looks like the
issue is caused by a dangling timer entry, i.e. a timer entry whose
owner/scheduler has been deleted.
Best regards,
Ming
On Thu, May 30, 2019 at 9:16 PM Ross Beer ross.beer@outlook.com wrote:
Hi Ming,
I am using Asterisk bundled, which is PJSIP 2.8 with patches:
"Fixed #2191:
- Stricter double timer entry scheduling prevention.
- Integrate group lock in SIP transport, e.g: for add/dec ref, for
timer scheduling."
I am have just had a further crash in a different location, which looks
like its crashed due to a timer entry being cancelled and an error is
happening while moving nodes. Is more locking required when performing
operations on the timer heap?
Thread 1 (Thread 0x7f783ebfa700 (LWP 83829)):
#0 0x00007f7ae3dc0249 in copy_node (ht=0x184cbf0, slot=2305,
moved_node=0x7f797732f0c0) at ../src/pj/timer.c:137
#1 0x00007f7ae3dc0677 in reheap_up (ht=0x184cbf0,
moved_node=0x7f780e0f2990, slot=2305, parent=1152) at ../src/pj/timer.c:208
#2 0x00007f7ae3dc0882 in remove_node (ht=0x184cbf0, slot=2305) at
../src/pj/timer.c:254
parent = 1152
moved_node = 0x7f780e0f2990
removed_node = 0x7f797f4a9e08
#3 0x00007f7ae3dc0b64 in cancel (ht=0x184cbf0, entry=0x7f797f4a9e08,
flags=1) at ../src/pj/timer.c:353
timer_node_slot = 2305
#4 0x00007f7ae3dc1061 in cancel_timer (ht=0x184cbf0,
entry=0x7f797f4a9e08, flags=0, id_val=0) at ../src/pj/timer.c:591
count = 32634
#5 0x00007f7ae3dc10ea in pj_timer_heap_cancel (ht=0x184cbf0,
entry=0x7f797f4a9e08) at ../src/pj/timer.c:611
#6 0x00007f7ae3d0f0c8 in pjsip_endpt_cancel_timer (endpt=0x184c908,
entry=0x7f797f4a9e08) at ../src/pjsip/sip_endpoint.c:848
#7 0x00007f7ae3cf62f6 in set_timer (sub=0x7f797f4a9cc8, timer_id=2,
seconds=3600) at ../src/pjsip-simple/evsub.c:508
#8 0x00007f7ae3cf91cc in on_tsx_state_uas (sub=0x7f797f4a9cc8,
tsx=0x7f780e0f27d8, event=0x7f783ebf98c0) at
../src/pjsip-simple/evsub.c:2172
expires = 0x7f7a10f9e600
tdata = 0x7f799cbcc068
st_code = 200
st_text = 0x0
body = 0x0
old_state = PJSIP_EVSUB_STATE_ACTIVE
old_state_str = {ptr = 0x7f7ae3dc6f0c "ACTIVE", slen = 6}
reason = {ptr = 0x0, slen = 0}
rdata = 0x7f7a10f95a68
msg = 0x7f7a10f9dac0
res_hdr = {prev = 0x7f783ebf9700, next = 0x7f783ebf9700, type =
284812696, name = {ptr = 0x7f797e162ca8 "", slen = 284809960}, sname = {ptr
= 0x7f797f4a9cc8 "evsub0x7f797f4a9cc8", slen = 140154425546736}, vptr =
0x7f7ae3cf7f2f <on_new_transaction+724>}
status = 0
event_hdr = 0x7f7a10f9e548
Kind regards,
Ross
From: pjsip pjsip-bounces@lists.pjsip.org on behalf of Ming <
ming@teluu.com>
Sent: 30 May 2019 07:20
To: pjsip list
Subject: Re: [pjsip] Segfault in timer.c
Hi Ross,
- Is there any steps or specific scenario to reproduce the issue?
- Which PJSIP version are you using? You mentioned ticket #2176, which
additional patches do you apply to the base version you're using? - Our latest fix with regard to the timer is ticket #2191
(https://trac.pjsip.org/repos/ticket/2191). Please let us know if the
problem still persists after this patch. Another ticket which may be
relevant is ticket #2172 (https://trac.pjsip.org/repos/ticket/2172). - For the stack trace which you provided, the crash seems to be caused
when accessing the node 0x7fa9c4c04c50. So, you will need to check
the PJSIP log, with PJ_TIMER_DEBUG on, and see to which component the
timer entry belongs, and when&how the pool which allocates the entry
gets destroyed, and why isn't the timer cancelled first before the
deallocation.
Regards,
Ming
On Tue, Apr 9, 2019 at 9:04 PM Ross Beer ross.beer@outlook.com wrote:
Hello,
The previous segfault was with issue #2176 (
https://trac.pjsip.org/repos/changeset/5934) patch applied, this patch
appears to increase the frequency of segfaults in the 'pj_timer_heap_poll'
process instead of mitigating them.
Can anyone offer assistance in getting this resolved?
Regards,
Ross
From: pjsip pjsip-bounces@lists.pjsip.org on behalf of Ross Beer <
Sent: 08 April 2019 17:05
To: pjsip@lists.pjsip.org
Subject: [pjsip] Segfault in timer.c
Hi,
We are seeing multiple segfaults while copying nodes:
Thread 1 (Thread 0x7fa977fff700 (LWP 36699)):
#0 0x00007fac956676fe in copy_node (ht=0x16d0410, slot=430,
moved_node=0x7fa9c4c04c50) at ../src/pj/timer.c:137
#1 0x00007fac956679d9 in reheap_down (ht=0x16d0410,
moved_node=0x7fab60031970, slot=430, child=862) at ../src/pj/timer.c:185
#2 0x00007fac95667d1d in remove_node (ht=0x16d0410, slot=0) at
../src/pj/timer.c:252
parent = 0
moved_node = 0x7fab60031970
removed_node = 0x7fa9b5978ae0
#3 0x00007fac95668634 in pj_timer_heap_poll (ht=0x16d0410,
next_delay=0x7fa977ffecd0) at ../src/pj/timer.c:634
node = 0x100000002
grp_lock = 0x31dc8c88
now = {sec = 8157205, msec = 523}
count = 0
#4 0x00007fac955b6b06 in pjsip_endpt_handle_events2 (endpt=0x16d0128,
max_timeout=0x7fa977ffed40, p_count=0x0) at ../src/pjsip/sip_endpoint.c:715
timeout = {sec = 0, msec = 0}
count = 0
net_event_count = 0
c = 0
#5 0x00007fac955b6c4b in pjsip_endpt_handle_events (endpt=0x16d0128,
max_timeout=0x7fa977ffed40) at ../src/pjsip/sip_endpoint.c:776
#6 0x00007faac8024bcf in monitor_thread_exec (endpt=0x0) at
res_pjsip.c:4512
delay = {sec = 0, msec = 10}
#7 0x00007fac9564fcb0 in thread_main (param=0x1815b28) at
../src/pj/os_core_unix.c:541
rec = 0x1815b28
result = 0x0
rc = 0
#8 0x00007fac9342ddd5 in start_thread () at /usr/lib64/libpthread.so.0
#9 0x00007fac927cfead in clone () at /usr/lib64/libc.so.6
Can anyone assist in resolving the issue?
Regards,
Ross
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Hi,
Yes, the early memory release without cancelling the timer entry is indeed
the most common problem, and most difficult to track.
We have recently created a stress test for the timer in ticket #2176 (
https://trac.pjsip.org/repos/ticket/2176). Still, it won't help much with
isolating the cause when an issue occurs.
Regards,
Ming
On Sat, Jun 1, 2019 at 9:45 AM shengy2019 via pjsip pjsip@lists.pjsip.org
wrote:
Hi Ming,
I meet a few crash(include this crash stack) in my project. But finally
the root cause for these issues(crash) all is the wrong application level
logic from the developer, such memory release.
So I suggest pjsip-developer need support better UNIT TEST for timer
module to make sure it work well, such as concurrency test. User's
application issue thould be checked by users-self.
发件人：pjsip-request pjsip-request@lists.pjsip.org
发送时间：2019年6月1日(星期六) 00:01
收件人：pjsip pjsip@lists.pjsip.org
主 题：pjsip Digest, Vol 141, Issue 22
Send pjsip mailing list submissions to
pjsip@lists.pjsip.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
or, via email, send a message with subject or body 'help' to
pjsip-request@lists.pjsip.org
You can reach the person managing the list at
pjsip-owner@lists.pjsip.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of pjsip digest..."
Today's Topics:
1. Re: Segfault in timer.c (Ming)
2. Crash when adding a video to the call (with ICE)
(Janusz Kolarczyk)
3. Re: Crash when adding a video to the call (with ICE) (Ming)
4. Re: Crash when adding a video to the call (with ICE)
(Janusz Kolarczyk)
5. Re: Crash when adding a video to the call (with ICE)
(Janusz Kolarczyk)
6. Re: Fixed dialog memory leak when no SDP in incoming INVITE
(mscdexdotexe)
7. vqrd, a vqrtcpxr collector server; lazy implementation of
rfc6035 (jrun)
Message: 1
Date: Fri, 31 May 2019 13:13:08 +0800
From: Ming ming@teluu.com
To: pjsip list pjsip@lists.pjsip.org
Subject: Re: [pjsip] Segfault in timer.c
Message-ID:
CAPimFqC-m4rAChJHX3TaMKR62QCYUZzyu0-OrL+7_OnM_BUCew@mail.gmail.com
Content-Type: text/plain; charset="utf-8"
Hi Ross,
I'm afraid the backtrace alone is not sufficient to pinpoint the cause. We
know that the current timer implementation is not easy to troubleshoot, and
we're thinking of changing it, but for now in order to investigate the
issue further, we will need to get additional information which I mentioned
in the previous email, such as the steps to reproduce, and/or the complete
PJSIP logs level 6 compiled with the timer debugging on.
And I don't think adding locks can help here, because it looks like the
issue is caused by a dangling timer entry, i.e. a timer entry whose
owner/scheduler has been deleted.
Best regards,
Ming
On Thu, May 30, 2019 at 9:16 PM Ross Beer ross.beer@outlook.com wrote:
Hi Ming,
I am using Asterisk bundled, which is PJSIP 2.8 with patches:
"Fixed #2191:
- Stricter double timer entry scheduling prevention.
- Integrate group lock in SIP transport, e.g: for add/dec ref, for
timer scheduling."
I am have just had a further crash in a different location, which looks
like its crashed due to a timer entry being cancelled and an error is
happening while moving nodes. Is more locking required when performing
operations on the timer heap?
Thread 1 (Thread 0x7f783ebfa700 (LWP 83829)):
#0 0x00007f7ae3dc0249 in copy_node (ht=0x184cbf0, slot=2305,
moved_node=0x7f797732f0c0) at ../src/pj/timer.c:137
#1 0x00007f7ae3dc0677 in reheap_up (ht=0x184cbf0,
moved_node=0x7f780e0f2990, slot=2305, parent=1152) at ../src/pj/timer.c:208
#2 0x00007f7ae3dc0882 in remove_node (ht=0x184cbf0, slot=2305) at
../src/pj/timer.c:254
parent = 1152
moved_node = 0x7f780e0f2990
removed_node = 0x7f797f4a9e08
#3 0x00007f7ae3dc0b64 in cancel (ht=0x184cbf0, entry=0x7f797f4a9e08,
flags=1) at ../src/pj/timer.c:353
timer_node_slot = 2305
#4 0x00007f7ae3dc1061 in cancel_timer (ht=0x184cbf0,
entry=0x7f797f4a9e08, flags=0, id_val=0) at ../src/pj/timer.c:591
count = 32634
#5 0x00007f7ae3dc10ea in pj_timer_heap_cancel (ht=0x184cbf0,
entry=0x7f797f4a9e08) at ../src/pj/timer.c:611
#6 0x00007f7ae3d0f0c8 in pjsip_endpt_cancel_timer (endpt=0x184c908,
entry=0x7f797f4a9e08) at ../src/pjsip/sip_endpoint.c:848
#7 0x00007f7ae3cf62f6 in set_timer (sub=0x7f797f4a9cc8, timer_id=2,
seconds=3600) at ../src/pjsip-simple/evsub.c:508
#8 0x00007f7ae3cf91cc in on_tsx_state_uas (sub=0x7f797f4a9cc8,
tsx=0x7f780e0f27d8, event=0x7f783ebf98c0) at
../src/pjsip-simple/evsub.c:2172
expires = 0x7f7a10f9e600
tdata = 0x7f799cbcc068
st_code = 200
st_text = 0x0
body = 0x0
old_state = PJSIP_EVSUB_STATE_ACTIVE
old_state_str = {ptr = 0x7f7ae3dc6f0c "ACTIVE", slen = 6}
reason = {ptr = 0x0, slen = 0}
rdata = 0x7f7a10f95a68
msg = 0x7f7a10f9dac0
res_hdr = {prev = 0x7f783ebf9700, next = 0x7f783ebf9700, type =
284812696, name = {ptr = 0x7f797e162ca8 "", slen = 284809960}, sname = {ptr
= 0x7f797f4a9cc8 "evsub0x7f797f4a9cc8", slen = 140154425546736}, vptr =
0x7f7ae3cf7f2f <on_new_transaction+724>}
status = 0
event_hdr = 0x7f7a10f9e548
Kind regards,
Ross
From: pjsip pjsip-bounces@lists.pjsip.org on behalf of Ming <
ming@teluu.com>
Sent: 30 May 2019 07:20
To: pjsip list
Subject: Re: [pjsip] Segfault in timer.c
Hi Ross,
- Is there any steps or specific scenario to reproduce the issue?
- Which PJSIP version are you using? You mentioned ticket #2176, which
additional patches do you apply to the base version you're using? - Our latest fix with regard to the timer is ticket #2191
(https://trac.pjsip.org/repos/ticket/2191). Please let us know if the
problem still persists after this patch. Another ticket which may be
relevant is ticket #2172 (https://trac.pjsip.org/repos/ticket/2172). - For the stack trace which you provided, the crash seems to be caused
when accessing the node 0x7fa9c4c04c50. So, you will need to check
the PJSIP log, with PJ_TIMER_DEBUG on, and see to which component the
timer entry belongs, and when&how the pool which allocates the entry
gets destroyed, and why isn't the timer cancelled first before the
deallocation.
Regards,
Ming
On Tue, Apr 9, 2019 at 9:04 PM Ross Beer ross.beer@outlook.com wrote:
Hello,
The previous segfault was with issue #2176 (
https://trac.pjsip.org/repos/changeset/5934) patch applied, this patch
appears to increase the frequency of segfaults in the 'pj_timer_heap_poll'
process instead of mitigating them.
Can anyone offer assistance in getting this resolved?
Regards,
Ross
From: pjsip pjsip-bounces@lists.pjsip.org on behalf of Ross Beer <
Sent: 08 April 2019 17:05
To: pjsip@lists.pjsip.org
Subject: [pjsip] Segfault in timer.c
Hi,
We are seeing multiple segfaults while copying nodes:
Thread 1 (Thread 0x7fa977fff700 (LWP 36699)):
#0 0x00007fac956676fe in copy_node (ht=0x16d0410, slot=430,
moved_node=0x7fa9c4c04c50) at ../src/pj/timer.c:137
#1 0x00007fac956679d9 in reheap_down (ht=0x16d0410,
moved_node=0x7fab60031970, slot=430, child=862) at ../src/pj/timer.c:185
#2 0x00007fac95667d1d in remove_node (ht=0x16d0410, slot=0) at
../src/pj/timer.c:252
parent = 0
moved_node = 0x7fab60031970
removed_node = 0x7fa9b5978ae0
#3 0x00007fac95668634 in pj_timer_heap_poll (ht=0x16d0410,
next_delay=0x7fa977ffecd0) at ../src/pj/timer.c:634
node = 0x100000002
grp_lock = 0x31dc8c88
now = {sec = 8157205, msec = 523}
count = 0
#4 0x00007fac955b6b06 in pjsip_endpt_handle_events2 (endpt=0x16d0128,
max_timeout=0x7fa977ffed40, p_count=0x0) at ../src/pjsip/sip_endpoint.c:715
timeout = {sec = 0, msec = 0}
count = 0
net_event_count = 0
c = 0
#5 0x00007fac955b6c4b in pjsip_endpt_handle_events (endpt=0x16d0128,
max_timeout=0x7fa977ffed40) at ../src/pjsip/sip_endpoint.c:776
#6 0x00007faac8024bcf in monitor_thread_exec (endpt=0x0) at
res_pjsip.c:4512
delay = {sec = 0, msec = 10}
#7 0x00007fac9564fcb0 in thread_main (param=0x1815b28) at
../src/pj/os_core_unix.c:541
rec = 0x1815b28
result = 0x0
rc = 0
#8 0x00007fac9342ddd5 in start_thread () at /usr/lib64/libpthread.so.0
#9 0x00007fac927cfead in clone () at /usr/lib64/libc.so.6
Can anyone assist in resolving the issue?
Regards,
Ross
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Hi Ming,
We are still facing timer issues and frequent segfaults. The PJSIP debug is producing a lot of information for every interaction.
What level debug would you need at the moment I'm gathering information at level 6?
Also, has there been any further movement on replacing the current timer implementation with something more elegant?
Regards,
Ross
From: pjsip pjsip-bounces@lists.pjsip.org on behalf of Ming ming@teluu.com
Sent: 04 June 2019 05:49
To: shengy2019; pjsip list
Subject: Re: [pjsip] Segfault in timer.c
Hi,
Yes, the early memory release without cancelling the timer entry is indeed the most common problem, and most difficult to track.
We have recently created a stress test for the timer in ticket #2176 (https://trac.pjsip.org/repos/ticket/2176). Still, it won't help much with isolating the cause when an issue occurs.
Regards,
Ming
On Sat, Jun 1, 2019 at 9:45 AM shengy2019 via pjsip <pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org> wrote:
Hi Ming,
I meet a few crash(include this crash stack) in my project. But finally the root cause for these issues(crash) all is the wrong application level logic from the developer, such memory release.
So I suggest pjsip-developer need support better UNIT TEST for timer module to make sure it work well, such as concurrency test. User's application issue thould be checked by users-self.
发件人：pjsip-request <pjsip-request@lists.pjsip.orgmailto:pjsip-request@lists.pjsip.org>
发送时间：2019年6月1日(星期六) 00:01
收件人：pjsip <pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org>
主 题：pjsip Digest, Vol 141, Issue 22
Send pjsip mailing list submissions to
pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
or, via email, send a message with subject or body 'help' to
pjsip-request@lists.pjsip.orgmailto:pjsip-request@lists.pjsip.org
You can reach the person managing the list at
pjsip-owner@lists.pjsip.orgmailto:pjsip-owner@lists.pjsip.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of pjsip digest..."
Today's Topics:
- Re: Segfault in timer.c (Ming)
- Crash when adding a video to the call (with ICE)
(Janusz Kolarczyk) - Re: Crash when adding a video to the call (with ICE) (Ming)
- Re: Crash when adding a video to the call (with ICE)
(Janusz Kolarczyk) - Re: Crash when adding a video to the call (with ICE)
(Janusz Kolarczyk) - Re: Fixed dialog memory leak when no SDP in incoming INVITE
(mscdexdotexe) - vqrd, a vqrtcpxr collector server; lazy implementation of
rfc6035 (jrun)
Message: 1
Date: Fri, 31 May 2019 13:13:08 +0800
From: Ming <ming@teluu.commailto:ming@teluu.com>
To: pjsip list <pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org>
Subject: Re: [pjsip] Segfault in timer.c
Message-ID:
<CAPimFqC-m4rAChJHX3TaMKR62QCYUZzyu0-OrL+7_OnM_BUCew@mail.gmail.commailto:CAPimFqC-m4rAChJHX3TaMKR62QCYUZzyu0-OrL%2B7_OnM_BUCew@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ross,
I'm afraid the backtrace alone is not sufficient to pinpoint the cause. We
know that the current timer implementation is not easy to troubleshoot, and
we're thinking of changing it, but for now in order to investigate the
issue further, we will need to get additional information which I mentioned
in the previous email, such as the steps to reproduce, and/or the complete
PJSIP logs level 6 compiled with the timer debugging on.
And I don't think adding locks can help here, because it looks like the
issue is caused by a dangling timer entry, i.e. a timer entry whose
owner/scheduler has been deleted.
Best regards,
Ming
On Thu, May 30, 2019 at 9:16 PM Ross Beer <ross.beer@outlook.commailto:ross.beer@outlook.com> wrote:
Hi Ming,
I am using Asterisk bundled, which is PJSIP 2.8 with patches:
"Fixed #2191:
- Stricter double timer entry scheduling prevention.
- Integrate group lock in SIP transport, e.g: for add/dec ref, for
timer scheduling."
I am have just had a further crash in a different location, which looks
like its crashed due to a timer entry being cancelled and an error is
happening while moving nodes. Is more locking required when performing
operations on the timer heap?
Thread 1 (Thread 0x7f783ebfa700 (LWP 83829)):
#0 0x00007f7ae3dc0249 in copy_node (ht=0x184cbf0, slot=2305,
moved_node=0x7f797732f0c0) at ../src/pj/timer.c:137
#1 0x00007f7ae3dc0677 in reheap_up (ht=0x184cbf0,
moved_node=0x7f780e0f2990, slot=2305, parent=1152) at ../src/pj/timer.c:208
#2 0x00007f7ae3dc0882 in remove_node (ht=0x184cbf0, slot=2305) at
../src/pj/timer.c:254
parent = 1152
moved_node = 0x7f780e0f2990
removed_node = 0x7f797f4a9e08
#3 0x00007f7ae3dc0b64 in cancel (ht=0x184cbf0, entry=0x7f797f4a9e08,
flags=1) at ../src/pj/timer.c:353
timer_node_slot = 2305
#4 0x00007f7ae3dc1061 in cancel_timer (ht=0x184cbf0,
entry=0x7f797f4a9e08, flags=0, id_val=0) at ../src/pj/timer.c:591
count = 32634
#5 0x00007f7ae3dc10ea in pj_timer_heap_cancel (ht=0x184cbf0,
entry=0x7f797f4a9e08) at ../src/pj/timer.c:611
#6 0x00007f7ae3d0f0c8 in pjsip_endpt_cancel_timer (endpt=0x184c908,
entry=0x7f797f4a9e08) at ../src/pjsip/sip_endpoint.c:848
#7 0x00007f7ae3cf62f6 in set_timer (sub=0x7f797f4a9cc8, timer_id=2,
seconds=3600) at ../src/pjsip-simple/evsub.c:508
#8 0x00007f7ae3cf91cc in on_tsx_state_uas (sub=0x7f797f4a9cc8,
tsx=0x7f780e0f27d8, event=0x7f783ebf98c0) at
../src/pjsip-simple/evsub.c:2172
expires = 0x7f7a10f9e600
tdata = 0x7f799cbcc068
st_code = 200
st_text = 0x0
body = 0x0
old_state = PJSIP_EVSUB_STATE_ACTIVE
old_state_str = {ptr = 0x7f7ae3dc6f0c "ACTIVE", slen = 6}
reason = {ptr = 0x0, slen = 0}
rdata = 0x7f7a10f95a68
msg = 0x7f7a10f9dac0
res_hdr = {prev = 0x7f783ebf9700, next = 0x7f783ebf9700, type =
284812696, name = {ptr = 0x7f797e162ca8 "", slen = 284809960}, sname = {ptr
= 0x7f797f4a9cc8 "evsub0x7f797f4a9cc8", slen = 140154425546736}, vptr =
0x7f7ae3cf7f2f <on_new_transaction+724>}
status = 0
event_hdr = 0x7f7a10f9e548
Kind regards,
Ross
From: pjsip <pjsip-bounces@lists.pjsip.orgmailto:pjsip-bounces@lists.pjsip.org> on behalf of Ming <
ming@teluu.commailto:ming@teluu.com>
Sent: 30 May 2019 07:20
To: pjsip list
Subject: Re: [pjsip] Segfault in timer.c
Hi Ross,
- Is there any steps or specific scenario to reproduce the issue?
- Which PJSIP version are you using? You mentioned ticket #2176, which
additional patches do you apply to the base version you're using? - Our latest fix with regard to the timer is ticket #2191
(https://trac.pjsip.org/repos/ticket/2191). Please let us know if the
problem still persists after this patch. Another ticket which may be
relevant is ticket #2172 (https://trac.pjsip.org/repos/ticket/2172). - For the stack trace which you provided, the crash seems to be caused
when accessing the node 0x7fa9c4c04c50. So, you will need to check
the PJSIP log, with PJ_TIMER_DEBUG on, and see to which component the
timer entry belongs, and when&how the pool which allocates the entry
gets destroyed, and why isn't the timer cancelled first before the
deallocation.
Regards,
Ming
On Tue, Apr 9, 2019 at 9:04 PM Ross Beer <ross.beer@outlook.commailto:ross.beer@outlook.com> wrote:
Hello,
The previous segfault was with issue #2176 (
https://trac.pjsip.org/repos/changeset/5934) patch applied, this patch
appears to increase the frequency of segfaults in the 'pj_timer_heap_poll'
process instead of mitigating them.
Can anyone offer assistance in getting this resolved?
Regards,
Ross
From: pjsip <pjsip-bounces@lists.pjsip.orgmailto:pjsip-bounces@lists.pjsip.org> on behalf of Ross Beer <
Sent: 08 April 2019 17:05
To: pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org
Subject: [pjsip] Segfault in timer.c
Hi,
We are seeing multiple segfaults while copying nodes:
Thread 1 (Thread 0x7fa977fff700 (LWP 36699)):
#0 0x00007fac956676fe in copy_node (ht=0x16d0410, slot=430,
moved_node=0x7fa9c4c04c50) at ../src/pj/timer.c:137
#1 0x00007fac956679d9 in reheap_down (ht=0x16d0410,
moved_node=0x7fab60031970, slot=430, child=862) at ../src/pj/timer.c:185
#2 0x00007fac95667d1d in remove_node (ht=0x16d0410, slot=0) at
../src/pj/timer.c:252
parent = 0
moved_node = 0x7fab60031970
removed_node = 0x7fa9b5978ae0
#3 0x00007fac95668634 in pj_timer_heap_poll (ht=0x16d0410,
next_delay=0x7fa977ffecd0) at ../src/pj/timer.c:634
node = 0x100000002
grp_lock = 0x31dc8c88
now = {sec = 8157205, msec = 523}
count = 0
#4 0x00007fac955b6b06 in pjsip_endpt_handle_events2 (endpt=0x16d0128,
max_timeout=0x7fa977ffed40, p_count=0x0) at ../src/pjsip/sip_endpoint.c:715
timeout = {sec = 0, msec = 0}
count = 0
net_event_count = 0
c = 0
#5 0x00007fac955b6c4b in pjsip_endpt_handle_events (endpt=0x16d0128,
max_timeout=0x7fa977ffed40) at ../src/pjsip/sip_endpoint.c:776
#6 0x00007faac8024bcf in monitor_thread_exec (endpt=0x0) at
res_pjsip.c:4512
delay = {sec = 0, msec = 10}
#7 0x00007fac9564fcb0 in thread_main (param=0x1815b28) at
../src/pj/os_core_unix.c:541
rec = 0x1815b28
result = 0x0
rc = 0
#8 0x00007fac9342ddd5 in start_thread () at /usr/lib64/libpthread.so.0
#9 0x00007fac927cfead in clone () at /usr/lib64/libc.so.6
Can anyone assist in resolving the issue?
Regards,
Ross
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.orgmailto:pjsip@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/20190531/40ccd955/attachment-0001.html
Message: 2
Date: Fri, 31 May 2019 10:24:49 +0200
From: Janusz Kolarczyk <januszkol@gmail.commailto:januszkol@gmail.com>
To: pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org
Subject: [pjsip] Crash when adding a video to the call (with ICE)
Message-ID:
<CAKpxDqw1SHwjEsDHQPQTXbfnUwcM3COrpdJ=XHujyv8G0nmBnw@mail.gmail.commailto:XHujyv8G0nmBnw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello.
In scenario:
UA 1 calling to UA 2. After connected UA 2 is trying to add video.
After call pjsua_call_set_vid_strm(callid, PJSUA_CALL_VID_STRM_ADD, NULL);
i got crash in func create_ice_media_transport section "/* Create ICE
stream transport configuration */"
It is caused because m is NULL after this: m =
call_med->call->async_call.rem_sdp->media[call_med->idx]; and next line: c
= m->conn? m->conn : call_med->call->async_call.rem_sdp->conn; is causing
crash.
m is NULL because call_med->call->async_call.rem_sdp has only one media and
call_med->idx is equal to 1.
Any idea? Am I doing something wrong? Or it is a bug?
Best Regards
Janusz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20190531/a1c3d0ec/attachment-0001.html
Message: 3
Date: Fri, 31 May 2019 17:44:30 +0800
From: Ming <ming@teluu.commailto:ming@teluu.com>
To: pjsip list <pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org>
Subject: Re: [pjsip] Crash when adding a video to the call (with ICE)
Message-ID:
<CAPimFqDyaQ0hC11CUZZybw6VpitEVADF2cEcnXgErPKW1b12cg@mail.gmail.commailto:CAPimFqDyaQ0hC11CUZZybw6VpitEVADF2cEcnXgErPKW1b12cg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Janusz,
I tested it here with the latest trunk version, adding video call with ICE,
and it seemed to work fine.
Which PJSIP version are you using and can you forward us the PJSIP log?
Regards,
Ming
On Fri, May 31, 2019 at 4:25 PM Janusz Kolarczyk <januszkol@gmail.commailto:januszkol@gmail.com>
wrote:
Hello.
In scenario:
UA 1 calling to UA 2. After connected UA 2 is trying to add video.
After call pjsua_call_set_vid_strm(callid, PJSUA_CALL_VID_STRM_ADD, NULL);
i got crash in func create_ice_media_transport section "/* Create ICE
stream transport configuration */"
It is caused because m is NULL after this: m =
call_med->call->async_call.rem_sdp->media[call_med->idx]; and next line: c
= m->conn? m->conn : call_med->call->async_call.rem_sdp->conn; is causing
crash.
m is NULL because call_med->call->async_call.rem_sdp has only one media
and call_med->idx is equal to 1.
Any idea? Am I doing something wrong? Or it is a bug?
Best Regards
Janusz
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.orgmailto:pjsip@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/20190531/6a89856c/attachment-0001.html
Message: 4
Date: Fri, 31 May 2019 11:49:11 +0200
From: Janusz Kolarczyk <januszkol@gmail.commailto:januszkol@gmail.com>
To: pjsip list <pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org>
Subject: Re: [pjsip] Crash when adding a video to the call (with ICE)
Message-ID:
<CAKpxDqyKg7CiZ8_DqBfDBWrxhePFwQ9GAb=nTgVZasxC5t5TTA@mail.gmail.commailto:nTgVZasxC5t5TTA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm using latest revision from svn
pt., 31 maj 2019 o 11:45 Ming <ming@teluu.commailto:ming@teluu.com> napisa?(a):
Hi Janusz,
I tested it here with the latest trunk version, adding video call with
ICE, and it seemed to work fine.
Which PJSIP version are you using and can you forward us the PJSIP log?
Regards,
Ming
On Fri, May 31, 2019 at 4:25 PM Janusz Kolarczyk <januszkol@gmail.commailto:januszkol@gmail.com>
wrote:
Hello.
In scenario:
UA 1 calling to UA 2. After connected UA 2 is trying to add video.
After call pjsua_call_set_vid_strm(callid, PJSUA_CALL_VID_STRM_ADD,
NULL); i got crash in func create_ice_media_transport section "/* Create
ICE stream transport configuration */"
It is caused because m is NULL after this: m =
call_med->call->async_call.rem_sdp->media[call_med->idx]; and next line: c
= m->conn? m->conn : call_med->call->async_call.rem_sdp->conn; is causing
crash.
m is NULL because call_med->call->async_call.rem_sdp has only one media
and call_med->idx is equal to 1.
Any idea? Am I doing something wrong? Or it is a bug?
Best Regards
Janusz
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.orgmailto:pjsip@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/20190531/60db6263/attachment-0001.html
Message: 5
Date: Fri, 31 May 2019 12:07:44 +0200
From: Janusz Kolarczyk <januszkol@gmail.commailto:januszkol@gmail.com>
To: pjsip list <pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org>
Subject: Re: [pjsip] Crash when adding a video to the call (with ICE)
Message-ID:
<CAKpxDqzqR0hCsRWMywy4H-6Dv6+X7YhVDUhDE=Htn7raRtjWPQ@mail.gmail.commailto:Htn7raRtjWPQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
And here are logs
pt., 31 maj 2019 o 11:49 Janusz Kolarczyk <januszkol@gmail.commailto:januszkol@gmail.com> napisa?(a):
I'm using latest revision from svn
pt., 31 maj 2019 o 11:45 Ming <ming@teluu.commailto:ming@teluu.com> napisa?(a):
Hi Janusz,
I tested it here with the latest trunk version, adding video call with
ICE, and it seemed to work fine.
Which PJSIP version are you using and can you forward us the PJSIP log?
Regards,
Ming
On Fri, May 31, 2019 at 4:25 PM Janusz Kolarczyk <januszkol@gmail.commailto:januszkol@gmail.com>
wrote:
Hello.
In scenario:
UA 1 calling to UA 2. After connected UA 2 is trying to add video.
After call pjsua_call_set_vid_strm(callid, PJSUA_CALL_VID_STRM_ADD,
NULL); i got crash in func create_ice_media_transport section "/* Create
ICE stream transport configuration */"
It is caused because m is NULL after this: m =
call_med->call->async_call.rem_sdp->media[call_med->idx]; and next line: c
= m->conn? m->conn : call_med->call->async_call.rem_sdp->conn; is causing
crash.
m is NULL because call_med->call->async_call.rem_sdp has only one media
and call_med->idx is equal to 1.
Any idea? Am I doing something wrong? Or it is a bug?
Best Regards
Janusz
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.orgmailto:pjsip@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/20190531/56872898/attachment-0001.html
-------------- next part --------------
12:01:10.430 os_core_unix.c pjlib 2.8-svn for POSIX initialized
12:01:10.430 sip_endpoint.c .Creating endpoint instance...
12:01:10.431 sip_endpoint.c .Module "mod-msg-print" registered
12:01:10.431 sip_transport.c .Transport manager created.
12:01:10.431 pjsua_core.c .PJSUA state changed: NULL --> CREATED
12:01:10.432 sip_endpoint.c .Module "mod-pjsua-log" registered
12:01:10.432 sip_endpoint.c .Module "mod-tsx-lay12:01:10.432 sip_endpoint.c .Module "mod-stateful-util" registered
12:01:10.432 sip_endpoint.c .Module "mod-ua" registered
12:01:10.432 sip_endpoint.c .Module "mod-100rel" registered
12:01:10.432 sip_endpoint.c .Module "mod-pjsua" registered
12:01:10.432 sip_endpoint.c .Module "mod-invite" registered
12:01:10.499 coreaudio_dev.c .. dev_id 0: iPhone IO device (in=1, out=1) 8000Hz
12:01:10.499 coreaudio_dev.c ..core audio initialized
12:01:10.500 speex_codec.c ..Adjusting quality to 5 for uwb
12:01:10.500 bcg729.c ..BCG729 codec initialized
12:01:10.500 conference.c ..Creating conference bridge with 12 ports
12:01:10.503 pjsua_vid.c ..Initializing video subsystem..
12:01:10.503 vid_conf.c ...Created video conference bridge with 32 ports
12:01:10.503 pj_vpx.c ...Init vpx codec
12:01:10.503 pj_vpx.c ...Enum codecs...
12:01:10.557 colorbar_dev.c ...Colorbar video src initialized with 2 device(s):
12:01:10.557 colorbar_dev.c ... 0: Colorbar generator
12:01:10.557 colorbar_dev.c ... 1: Colorbar-active
12:01:10.557 sip_endpoint.c .Module "mod-evsub" registered
12:01:10.557 sip_endpoint.c .Module "mod-presence" registered
12:01:10.557 evsub.c .Event pkg "presence" registered by mod-presence
endpoint.c .Module "mod-mwi" registered
12:01:10.557 evsub.c .Event pkg "message-summary" registered by mod-mwi
12:01:10.557 sip_endpoint.c .Module "mod-refer" registered
12:01:10.557 evsub.c .Event pkg "refer" registered by mod-refer
12:01:10.557 sip_endpoint.c .Module "mod-pjsua-pres" registered
12:01:10.557 sip_endpoint.c .Module "mod-pjsua-im" registered
12:01:10.557 sip_endpoint.c .Module "mod-pjsua-options" registered
.557 pjsua_core.c .1 SIP worker threads created
12:01:10.557 pjsua_core.c .pjsua version 2.8-svn for iOS-12.3.1/arm-iPhone10,6/iOS-SDK initialized
12:01:10.557 pjsua_core.c .PJSUA state changed: CREATED --> INIT
.557 sip_endpoint.c Module "" registered
12:01:10.557 sip_endpoint.c Module "info_typing_read_module" registered
12:01:10.557 pjsua_core.c PJSUA state changed: INIT --> STARTING
12:01:10.557 pjsua_core.c .PJSUA state changed: STARTING --> RUNNING
12:01:10.557 pjsua_aud.c Setting null sound device..
12:01:10.804 pjsua_aud.c .Opening null sound device..
12:01:10.804 config.c PJLIB (c)2008-2016 Teluu Inc.
12:01:10.804 config.c Dumping configurations:
12:01:10.804 config.c PJ_VERSION : 2.8-svn
12:01:10.804 config.c PJ_M_NAME : arm64
12:01:10.804 config.c PJ_HAS_PENTIUM : 0
12:01:10.804 config.c PJ_OS_NAME : arm64-apple-darwin_ios
10.804 config.c PJ_CC_NAME/VER_(1,2,3) : gcc-4.2.1
12:01:10.804 config.c PJ_IS_(BIG/LITTLE)_ENDIAN : little-endian
12:01:10.804 config.c PJ_HAS_INT64 : 1
12:01:10.804 config.c PJ_DEBUG : 1
12:01:10.804 config.c PJ_FUNCTIONS_ARE_INLINED : 0
12:01:10.804 config.c PJ_LOG_MAX_LEVEL : 6
12:01:10.804 config.c PJ_LOG_MAX_SIZE : 4000
12:01:10.804 config.c PJ_LOG_USE_STACK_BUFFER : 1
12:01:10.804 config.c PJ_POOL_DEBUG : 0
12:01:10.804 config.c PJ_HAS_POOL_ALT_API 12:01:10.804 config.c PJ_HAS_TCP : 1
12:01:10.804 config.c PJ_MAX_HOSTNAME : 128
12:01:10.804 config.c ioqueue type : select
12:01:10.804 config.c PJ_IOQUEUE_MAX_HANDLES : 64
12:01:10.804 config.c PJ_IOQUEUE_HAS_SAFE_UNREG : 1
12:01:10.804 config.c PJ_HAS_THREADS : 1
12:01:10.804 config.c PJ_LOG_USE_STACK_BUFFER : 1
config.c PJ_HAS_SEMAPHORE : 1
12:01:10.804 config.c PJ_HAS_EVENT_OBJ : 1
12:01:10.804 config.c PJ_ENABLE_EXTRA_CHECK : 1
12:01:10.804 config.c PJ_HAS_EXCEPTION_NAMES 12:01:10.804 config.c PJ_MAX_EXCEPTION_ID : 16
12:01:10.804 config.c PJ_EXCEPTION_USE_WIN32_SEH: 0
12:01:10.804 config.c PJ_TIMESTAMP_USE_RDTSC: : 0
12:01:10.804 config.c PJ_12:01:10.804 config.c PJ_HAS_HIGH_RES_TIMER : 1
12:01:10.804 config.c PJ_HAS_IPV6 : 1
:01:10.812 pj_vpx.c vpx default attr
12:01:10.926 pjsua_core.c .STUN resolution success, using sip.voipswitchr12:01:10.926 stun_session.c .tdata 0x167c51028 destroy request, force=0, tsx=0x167c511b0
pjsua_acc.c .Account "48504421128"<sip:48504421128@sip.voipswitchrcs.commailto:sip%3A48504421128@sip.voipswitchrcs.com;transport=tls> added with id 0
12:01:11.009 pjsua_acc.c Adding account: id="48504421128"<sip:48504421128@sip.voi12:01:11.009 pjsua_acc.c .Account "48504421128"<sip:48504421128@sip.voipswitchrcs.commailto:sip%3A48504421128@sip.voipswitchrcs.com;transport=tls> added with id 1
pjsua_acc.c Acc 0: setting registration..
12:01:11.013 sip_resolve.c ..DNS resolver not available, target 'sip.voipswitchrcs.com:0http://sip.voipswitchrcs.com:0' type=TLS will be resolved with getaddrinfo()
12:01:11.014 sip_resolve.c ..Target 'sip.voipswitchrc12:01:11.014 pjsua_core.c ..TX 742 bytes Request msg REGISTER/cseq=11001 (tdta0x17d33d5a8) to TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:11.014 pjsua_acc.c .Acc 0: Registration sent
12:01:11.228 stun_session.c STUN transaction 0x167c511b0 destroyed
12:01:11.228 stun_session.c STUN session 0x17c119aa8 destroyed
12:01:11.273 sip_endpoint.c Processing incoming message: Response msg 401/REGISTER/cseq=11001 (rdata0x169528848)
12:01:11.274 pjsua_core.c .RX 478 bytes Response msg 401/REGISTER/cseq=11001 (rdata0x169528848) from TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:11.275 pjsua_core.c ....TX 946 sip_endpoint.c Processing incoming message: Response msg 100/REGISTER/cseq=11002 (rdata0x169528848)
12:01:11.337 pjsua_core.c .RX 362 bytes Response msg 100/REGISTER/cseq=11002 (rdata0x169528848) from TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:11.386 sip_endpoint.c Processing incoming message: Response msg 200/REGISTER/cseq=11002 (rdata0x169528848)
12:01:11.386 pjsua_core.c .RX 454 bytes Response msg 200/REGISTER/cseq=11002 (rdata0x169528848) from TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:11.386 pjsua_acc.c ....SIP outbound status for acc 0 is not active
12:01:11.386 pjsua_acc.c ...."48504421128"<sip:48504421128@sip.voipswitchrcs.commailto:sip%3A48504421128@sip.voipswitchrcs.com;transport=tls>: registration success, status=200 (OK), will re-register in 3600 seconds
12:01:11.390 sip_resolve.c ..DNS12:01:11.391 sip_resolve.c ..Target 'sip.voipswitchrcs.com:0http://sip.voipswitchrcs.com:0' type=TLS resolved to '63.32.153.19:5061http://63.32.153.19:5061' type=TLS (TLS transport)
pjsua_core.c ..TX 1218 bytes Request msg PUBLISH/cseq=54225 (tdta0x17d34b1a8) to TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:11.485 pjsua_core.c .RX 477 bytes Response msg 401/PUBLISH/cseq=54225 (rdata0x169528848) from TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:11.485 pjsua_core.c ....TX 1434 bytes Request msg PUBLISH/cseq=54226 (tdta0x17d34b1a8) to TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:11.541 sip_endpoint.c Processing incoming message: Response msg 100/PUBLISH/cseq=54226 (rdata0x169528848)
12:01:11.541 pjsua_core.c .RX 361 bytes Response msg 100/PUBLISH/cseq=54226 (rdata0x169528848) from TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:11.596 sip_endpoint.c Processing incoming message: Response msg 200/PUBLISH/cseq=54226 (rdata0x169528848)
12:01:11.596 pjsua_core.c .RX 417 bytes Response msg 200/PUBLISH/cseq=54226 (rdata0x169528848) from TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:39.318 sip_endpoint.c Processing incoming message: Request msg INVITE/cseq=1 (rdata0x169528848)
12:01:39.318 pjsua_core.c .RX 1326 bytes Request msg INVITE/cseq=1 (rdata0x169528848) from TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:39.318 pjsua_call.c .Incoming Request msg INVITE/cseq=1 (rdata0x169528848)
12:01:39.320 pjsua_media.c ..Call 0: initializing media..
edia.c ...Media index 0 selected for audio call 0
12:01:43.178 pjsua_core.c .....TX 328 bytes Response msg 100/INVITE/cseq=1 (tdta0x17d2975a8) to TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:52.464 pjsua_call.c ..Answering call 0: code=180
12:01:52.464 pjsua_call.c ...Pending answering call 0 upon completion of media transport
12:01:52.466 stun_session.c .tdata 0x167c1a028 destroy request, force=0, tsx=0x167c1a1b0
12:01:52.466 stun_session.c .tdata 0x292e16e28 destroy request, force=0, tsx=0x292e16fb0
12:01:52.467 pjsua_media.c Call 0: media transport initialization complete: Success
12:01:52.468 pjsua_call.c Answering call 0: code=180
12:01:52.468 sip_transport.c ..Tx data Respon12:01:52.468 pjsua_core.c ..12:01:52.769 stun_session.c STUN transaction 0x292e16fb0 destroyed
12:01:52.769 stun_session.c STUN transaction 0x167c1a1b0 destroyed
12:01:54.824 sip_transport.c ..Tx data Response msg 180/INVITE/cseq=1 (tdta0x17d2939a8) cloned
12:01:54.824 pjsua_media.c ...Call 0: updating media..
12:01:54.824 pjsua_media.c .....Media stream call00:0 is destroyed
12:01:54.825 pjsua_aud.c ....Audio channel update..
12:01:54.825 rtp.c .....pjmedia_rtp_session_init: ses=0x167c5fd58, default_pt=18, ssrc=0x14f1a551
12:01:54.825 rtp.c .....pjmedia_rtp_session_init: ses=12:01:54.825 stream.c .....Stream strm0x1694f0128 created
:54.825 resample.c .....resample created: high qualiy, small filter, in/out rate=8000/32000
12:01:54.825 resample.c .....resample created: high qualiy, small filter, in/out rate=32000/8000
12:01:54.825 pjsua_media.c ..12:01:54.825 pjsua_aud.c ...Conf connect: 2 --> 0
5 conference.c ....Port 2 (sip:48732104220@63.32.153.19:5061http://sip:48732104220@63.32.153.19:5061) transmitting to port 0 (Master/sound)
12:01:54.825 pjsua_aud.c ...Conf connect: 0 --> 2
12:01:54.825 conference.c ....Port 0 (Master/sound) transmitting to po12:01:54.828 pjsua_core.c ....TX 1838 bytes Response msg 200/INVITE/cseq=1 (tdta0x17d2939a8) to TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:55.101 pjsua_aud.c .Opening null sound device..
12:01:55.101 pjsua_aud.c Set sound device: capture=-1, playback=-2
12:01:55.103 pjsua_aud.c ..Closing null sound device..
12:01:55.122 coreaudio_dev.c ..Using VoiceProcessingIO audio unit
jsua_core.c .TX 1838 bytes Response msg 200/INVITE/cseq=1 (tdta0x17d2939a8) to TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:55.414 os_core_unix.c Info: possibly re-registering existing thread
12:01:57.132 sip_endpoint.c Processing incoming message: Request msg ACK/cseq=1 (rdata0x169528848)
12:01:57.133 pjsua_core.c .RX 453 bytes Request msg ACK/cseq=1 (rdata0x169528848) from TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:57.642 stun_session.c .tdata 0x167c91128 destroy request, force=0, tsx=0x167c91300
12:01:57.659 stun_session.c .tdata 0x167cc1d28 destroy request, force=0, tsx=0x167cc1f00
12:01:57.661 stun_session.c .tdata 0x167cb8c212:01:57.661 stun_session.c .tdata 0x167cd6728 destroy request, force=0, tsx=0x167cd6900
12:01:57.661 stun_session.c .tdata 0x167cb2328 destroy request, force=0, tsx=0x167cb2500
1:57.661 stun_session.c .tdata 0x167c25428 destroy request, force=0, tsx=0x167c25600
12:01:57.661 stun_session.c .tdata 0x167c06028 destroy request,12:01:57.661 stun_session.c .tdata 0x167cd3528 destroy request, force=0, tsx=0x167cd3700
12:01:57.662 stun_session.c .tdata 0x292e05628 destroy request, force=0, tsx=0x292e05800
12:01:57.662 stun_session.c 12:01:57.662 stun_session.c .tdata 0x167cd5d28 destroy request, force=0, tsx=0x167cd5f00
12:01:57.662 stun_session.c .tdata 0x167c18un_session.c .tdata 0x167c20e28 destroy request, force=0, tsx=0x167c21000
12:01:57.670 stun_session.c .tdata 0x167cda328 destroy request, force=0, tsx=0x167cd12:01:57.670 stun_session.c .tdata 0x167c0ec28 destroy request, force=0, tsx=0x167c0ee00
12:01:57.670 stun_session.c .tdata 0x167c9d428 destroy request, force=0, tsx=0x167c9d600
12:01:57.670 stun_session.c .tdata 012:01:57.670 stun_session.c .tdata 0x167cf2928 destroy request, force=0, tsx=0x167cf2b00
12:01:57.670 stun_session.c .tdata 0x167cf2428 destroy request, force=0, tsx=0x167cf2600
70 stun_session.c .tdata 0x167ccf428 destroy request, force=0, tsx=0x167ccf600
12:01:57.670 stun_session.c .tdata 0x167c89e28 destroy request, force=012:01:57.671 stun_session.c .tdata 0x292e1dc28 destroy request, force=0, tsx=0x292e1de00
12:01:57.671 stun_session.c .tdata 0x292e17d28 destroy request, force=0, tsx=0x292e17f00
12:01:57.671 stun_session.c .tdata 0x167c89928 destroy request, force=0, tsx=01:57.675 sip_endpoint.c Processing incoming message: Request msg UPDATE/cseq=2 (rdata0x169528848)
12:01:57.675 pjsua_core.c .RX 1038 bytes Request msg UPDATE/cseq=2 (rdata0x169528848) from TLS 63.32.153.19:5061http://63.32.153.19:5061:
12:01:57.676 pjsua_call.c .....Call 0: received updated media offer
12:01:57.677 pjsua_media.c ......Call 0: re-initializing media..
12:01:57.677 pjsua_media.c .......Media index 0 selected for audio call 0
12:01:57.678 pjsua_media.c ......Call 0: updating media..
12:01:57.678 pjsua_media.c ........Media stream call00:0 is destroyed
12:01:57.679 pjsua_aud.c .......Audio channel update..
12:01:57.679 rtp.c ........pjmedia_rtp_session_init: ses=0x167cf7b58, default_pt=18, ssrc=0x14f1a551
12:01:57.679 rtp.c ........pjmedia_rtp_session_i12:01:57.679 stream.c ........Stream strm0x169412128 created
12:01:57.679 resample.c ........resample created: high qualiy, small filter, in/out rate=8000/32000
12:01:57.679 resample.c ........resample created: high qualiy, small filter, in/out rate=32000/8000
pjsua_media.c .......Audio updated, stream #0: G729 (sendrecv)
12:01:57.680 pjsua_aud.c ......Conf connect: 2 --> 0
12:01:57.680 conference.c .......Port 2 (sip:4873210412:01:57.680 pjsua_aud.c ......Conf connect: 0 --> 2
12:01:57.680 conference.c .......Port 0 (iPhone IO device) transmitting to port 2 (sip:48732104220@63.32.153.19:512:01:57.685 pjsua_core.c .......TX 1280 bytes Response msg 200/UPDATE/cseq=2 (tdt12:01:57.943 stun_session.c STUN transaction 0x167c91300 destroyed
12:01:57.960 stun_session.c STUN transaction 0x167cc1f00 destroyed
12:01:57.962 stun_session.c STUN transaction 0x167cb8e00 destroyed
12:01:57.962 stun_session.c STUN transaction 0x167cd6900 destroyed
12:01:57.962 stun_session.c STUN transaction 0x167c25600 destroyed
12:01:57.962 stun_session.c STUN transaction 0x167c06200 destroyed
12:01:57.962 stun_session.c STUN transaction 0x167cb2500 destroyed
12:01:57.962 stun_session.c STUN transaction 0x167cd5f00 destroyed12:01:57.962 stun_session.c STUN transaction 0x167c18e00 destroyed
12:01:57.962 stun_session.c STUN transaction 0x167cd3700 destroyed
12:01:57.962 stun_session.c STUN transaction 0x167c67a00 destroyed
12:01:57.962 stun_session.c STUN transaction 0x292e05800 destroyed
12:01:57.973 stun_session.c STUN transaction 0x167c9d600 destroyed
12:01:57.973 stun_session.c STUN transaction 0x167cda500 destroyed
12:01:57.973 stun_session.c STUN transaction 0x167c21000 destroyed
12:01:57.973 stun_session.c STUN transaction 0x167c60c00 destroyed
12:01:57.973 stun_session.c STUN transaction 0x167c0ee00 destroyed
12:01:57.973 stun_session.c STUN transaction 0x167cf2b00 destroyed12:01:57.973 stun_session.c STUN transaction 0x167cf2600 destroyed
12:01:57.973 stun_session.c STUN transaction 0x292e17f00 destroyed
12:01:57.973 stun_session.c STUN transaction 0x167c89b00 destroye12:01:57.973 stun_session.c STUN transaction 0x167c8a000 destroyed
12:01:57.973 stun_session.c STUN transaction 0x167ccf600 destroyed
12:01:57.973 stun_session.c STUN transaction 0x292e1de00 destroyed
12:02:07.420 stun_session.c tdata 0x292e08828 destroy request, force=0, tsx=0x0
12:02:07.422 stun_session.c tdata 0x167c12828 destroy request, force=0, tsx=0x0
12:02:07.423 stun_session.c tdata 0x167c15528 destroy request, force=0, tsx=0x0
12:02:07.522 stun_session.c .tdata 0x167cfc928 destroy request, force=0, tsx=0x167cfcab0
12:02:07.522 stun_session.c .tdata 0x167cf9228 destroy request, force=0, tsx=0x167cf93b0
12:02:07.642 stun_session.c tdata 0x292e10028 destroy request, force=0, tsx=0x0
12:02:07.661 stun_session.c tdata 0x167c01a28 destroy request, force=0, tsx=0x0
12:02:07.664 stun_session.c tdata 0x167c42a28 destroy request, force=0, tsx=0x0
12:02:07.664 stun_session.c tdata 0x167c71d28 destroy request, force=0, tsx=0x0
12:02:07.665 stun_session.c tdata 0x167c47528 destroy request, force=0, tsx=0x0
12:02:07.667 stun_session.c tdata 0x167cb8728 destroy request, force=0, tsx=0x0
12:02:07.667 stun_session.c tdata 0x167cb7d28 destroy request, force=0, tsx=0x0
12:02:07.667 stun_session.c tdata 0x167c2f428 destroy request, force=0, tsx=0x0
12:02:07.668 stun_session.c tdata 0x167cf5128 destroy request, force=0, tsx=0x0
12:02:07.668 stun_session.c tdata 0x167cf5628 destroy request, force=0, tsx=0x0
12:02:07.822 stun_session.c STUN transaction 0x167cfcab0 destroyed
12:02:07.823 stun_session.c STUN transaction 0x167cf93b0 destroyed
12:02:08.672 stun_session.c .tdata 0x167c1dc28 destroy request, force=0, tsx=0x0
12:02:19.674 stun_session.c .tdata 0x167c83f28 destroy request, force=0, tsx=0x0
12:02:20.273 pjsua_vid.c Call 0: set video stream, op=1
Message: 6
Date: Fri, 31 May 2019 07:25:24 -0400
From: mscdexdotexe <mscdex@mscdex.netmailto:mscdex@mscdex.net>
To: pjsip list <pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org>
Subject: Re: [pjsip] Fixed dialog memory leak when no SDP in incoming
INVITE
Message-ID:
<CAPqAjCzka=HFXmTe5_4FBaQtwx9bnkjG54V-T6kZbZMFbcuZKA@mail.gmail.commailto:HFXmTe5_4FBaQtwx9bnkjG54V-T6kZbZMFbcuZKA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Fri, Apr 5, 2019 at 1:40 PM mscdexdotexe <mscdex@mscdex.netmailto:mscdex@mscdex.net> wrote:
Hello,
Since 4b36447313032c1aaa0a68a91066b44e86c5e466 there has been a dialog
memory leak when an INVITE is received without an SDP. I have attached a
patch (against master) that fixes the leak.
For testing I used a simple pjsua UAS program (attached -- repro.c) and
two different SIPp[1] scenarios (one with SDP in INVITE and one with SDP
later in the ACK -- both attached). After the final transaction is
terminated 30 seconds after the call ends (typically when the dialog would
get destroyed) you can send SIGUSR2 to the pjsua UAS program to display the
dialog sets still in memory. Before this patch, the sip-ack scenario should
show a single dialog set. With the sipp-invite (and after this patch +
sipp-ack) scenario, there should be no dialog sets shown.
The SIPp scenarios can be used via: sipp -sf <scenario file> -m 1 -r 1 -l
1 <ip where pjsua UAS program is running>:5070
Is it possible to get this patch merged in?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20190531/e4510714/attachment-0001.html
Message: 7
Date: Fri, 31 May 2019 10:15:42 -0400
From: jrun <darwinskernel@gmail.commailto:darwinskernel@gmail.com>
To: pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org
Subject: [pjsip] vqrd, a vqrtcpxr collector server; lazy
implementation of rfc6035
Message-ID: 20190531141542.GA5105@zorro
Content-Type: text/plain; charset=utf-8
hello,
just put out my lazy attempt at implementing rfc6035's collector here:
comments/patches are welcome.
jrun
Subject: Digest Footer
pjsip mailing list
pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
End of pjsip Digest, Vol 141, Issue 22
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.orgmailto:pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org