[asterisk-dev] Asterisk Segfault After PJSIP Commit 5241

[Michael Ulitskiy]

Hello,

Please see this discussion http://lists.digium.com/pipermail/asterisk-dev/2015-October/075122.html
I guess you're talking about the same problem.

Michael

On Tuesday, March 01, 2016 06:26:27 PM Ross Beer wrote:
> Hi George,
>  
> We need to store contacts in realtime for our system. However not all endpoints are registered only about 200, yet asterisk loops through every endpoint which has been defined. It does this if contacts are in realtime or not.
>  
> Its almost like pjsip is loading them to check if they need to be qualified etc.
>  
> Asterisk 1.8 only put things into cache once they were accessed, is this an option for sourcery?
>  
> Thanks,
>  
> Ross
>  
> From: george.joseph at fairview5.com
> Date: Tue, 1 Mar 2016 10:42:58 -0700
> To: asterisk-dev at lists.digium.com
> Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
> 
> 
> 
> On Tue, Mar 1, 2016 at 10:29 AM, Ross Beer <ross.beer at outlook.com> wrote:
> 
> 
> 
> Hi George,
>  
> I have now got asterisk 13 trunk, however loading is very slow. This is due to asterisk reading all of the realtime Sorcery peers and marking them all as 'Unknown'. Is there a way to only cache peers that have tried to register?
> 
> 
> ​When you say "Asterisk 13 trunk"​ ​you do mean "branch"​ correct?
> ​Assuming you have contacts coming from realtime, the only was to prevent them from being qualified is to ​delete them from the ps_contacts table before starting Asterisk.  You really don't gain anything by using realtime for contacts anyway.  I'd just disable it and let Asterisk use the internal sqlite3 database to keep track of them. 
>  
> So far its taking 20 mins to load!!
>  
> Also asterisk has the following warning:
>  
> taskprocessor.c:803 taskprocessor_push: The 'subm:ast_device_state_topic-000055d0' task processor queue reached 500 scheduled tasks.
>  
> 
> ​Whoa!​  This makes me think I might have messed something up in the fix for contacts not being cached correctly.
> Don't use realtime for contacts and see what happens.  I'm going to re-test.
>  Neither were issues in the previous release.
>  
> Thank you for your assistance,
>  
> Ross
>  
> From: george.joseph at fairview5.com
> Date: Tue, 1 Mar 2016 09:08:37 -0700
> To: asterisk-dev at lists.digium.com
> Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
> 
> 
> 
> On Tue, Mar 1, 2016 at 5:58 AM, Ross Beer <ross.beer at outlook.com> wrote:
> 
> 
> 
> Further to my previous email it appears this bug won't be easily resolved by changing the method:
>  
> pjsip_dlg_create_uas() >> pjsip_dlg_create_uas_and_inc_lock().
>  
> Asterisk starts ok, allows registrations but no calls progress.
> 
> 
> ​You have to pull Asterisk from the 13 branch.  ​This should have been fixed with review 2236 and I've been running with that patch and pjproject trunk.
>  
>  
> From: ross.beer at outlook.com
> To: asterisk-dev at lists.digium.com
> Date: Tue, 1 Mar 2016 11:49:55 +0000
> Subject: Re: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
> 
> 
> 
> 
> I've just found an open issue for this https://issues.asterisk.org/jira/browse/ASTERISK-25751
> 
>  
> From: ross.beer at outlook.com
> To: asterisk-dev at lists.digium.com
> Date: Tue, 1 Mar 2016 11:06:09 +0000
> Subject: [asterisk-dev] Asterisk Segfault After PJSIP Commit 5241
> 
> 
> 
> 
>  Hi,
> 
> Since PJSIP Commit 5241 (https://trac.pjsip.org/repos/changeset/5241) Asterisk crashes when a device registers.
> 
> The commit resolves the following:
>  
> • Crash when endpoint has multiple worker threads and SIP TCP transport is disconnected during incoming call handling.
> • Deprecated pjsip_dlg_create_uas(), replaced by pjsip_dlg_create_uas_and_inc_lock().
> • Serialized transaction state notifications (of 'terminated' and 'destroyed') in case of transport error.
>  
> This commit should resolve a previous segfault within Asterisk, however due to the deprecated method I believe this is causing an additional issue. 
>  
> Can this be easily resolved to resolve both segfaults?
>  
> Kind regards,
>  
> Ross
> 
>  
>  
>  
>  		 	   		  
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160301/e2568d7a/attachment-0001.html>