|
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@xxxxxxxxxxxxxxx> on behalf of Ming <ming@xxxxxxxxx>
Sent: 04 June 2019 05:49
To: shengy2019; pjsip list
Subject: Re: 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.
Regards,
Ming
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.
------------------------------------------------------------------
发送时间：2019年6月1日(星期六) 00:01
主 题：pjsip Digest, Vol 141, Issue 22
Send pjsip mailing list submissions to
pjsip@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
You can reach the person managing the list at
pjsip-owner@xxxxxxxxxxxxxxx
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@xxxxxxxxx>
To: pjsip list <pjsip@xxxxxxxxxxxxxxx>
Subject: Re: Segfault in timer.c
Message-ID:
<CAPimFqC-m4rAChJHX3TaMKR62QCYUZzyu0-OrL+7_OnM_BUCew@xxxxxxxxxxxxxx>
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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> on behalf of Ming <
> ming@xxxxxxxxx>
> *Sent:* 30 May 2019 07:20
> *To:* pjsip list
> *Subject:* Re: 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> on behalf of Ross Beer <
> ross.beer@xxxxxxxxxxx>
> > Sent: 08 April 2019 17:05
> > To: pjsip@xxxxxxxxxxxxxxx
> > Subject: 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@xxxxxxxxxxxxxxx
> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip@xxxxxxxxxxxxxxx
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip@xxxxxxxxxxxxxxx
> 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@xxxxxxxxx>
To: pjsip@xxxxxxxxxxxxxxx
Subject: Crash when adding a video to the call (with ICE)
Message-ID:
<CAKpxDqw1SHwjEsDHQPQTXbfnUwcM3COrpdJ=XHujyv8G0nmBnw@xxxxxxxxxxxxxx>
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@xxxxxxxxx>
To: pjsip list <pjsip@xxxxxxxxxxxxxxx>
Subject: Re: Crash when adding a video to the call (with ICE)
Message-ID:
<CAPimFqDyaQ0hC11CUZZybw6VpitEVADF2cEcnXgErPKW1b12cg@xxxxxxxxxxxxxx>
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@xxxxxxxxx>
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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxx>
To: pjsip list <pjsip@xxxxxxxxxxxxxxx>
Subject: Re: Crash when adding a video to the call (with ICE)
Message-ID:
<CAKpxDqyKg7CiZ8_DqBfDBWrxhePFwQ9GAb=nTgVZasxC5t5TTA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
I'm using latest revision from svn
pt., 31 maj 2019 o 11:45 Ming <ming@xxxxxxxxx> 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@xxxxxxxxx>
> 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@xxxxxxxxxxxxxxx
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip@xxxxxxxxxxxxxxx
> 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@xxxxxxxxx>
To: pjsip list <pjsip@xxxxxxxxxxxxxxx>
Subject: Re: Crash when adding a video to the call (with ICE)
Message-ID:
<CAKpxDqzqR0hCsRWMywy4H-6Dv6+X7YhVDUhDE=Htn7raRtjWPQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
And here are logs
pt., 31 maj 2019 o 11:49 Janusz Kolarczyk <januszkol@xxxxxxxxx> napisa?(a):
> I'm using latest revision from svn
>
> pt., 31 maj 2019 o 11:45 Ming <ming@xxxxxxxxx> 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@xxxxxxxxx>
>> 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@xxxxxxxxxxxxxxx
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip@xxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxxxx;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@xxxxxxxxxxxxxxxxxxxxx;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: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: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: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: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: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@xxxxxxxxxxxxxxxxxxxxx;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:0' type=TLS resolved to '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:5061:
12:01:11.485 pjsua_core.c .RX 477 bytes Response msg 401/PUBLISH/cseq=54225 (rdata0x169528848) from TLS 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: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: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: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: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: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: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: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: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: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: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@xxxxxxxxxx>
To: pjsip list <pjsip@xxxxxxxxxxxxxxx>
Subject: Re: Fixed dialog memory leak when no SDP in incoming
INVITE
Message-ID:
<CAPqAjCzka=HFXmTe5_4FBaQtwx9bnkjG54V-T6kZbZMFbcuZKA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
On Fri, Apr 5, 2019 at 1:40 PM mscdexdotexe <mscdex@xxxxxxxxxx> 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
>
>
> [1] https://github.com/SIPp/sipp
>
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@xxxxxxxxx>
To: pjsip@xxxxxxxxxxxxxxx
Subject: 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:
https://gitlab.com/257/vrqd
comments/patches are welcome.
-
jrun
------------------------------
Subject: Digest Footer
_______________________________________________
pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
|
