[asterisk-dev] ASTERISK-26145 - Task Process Issues possibly caused by HEP

[Ross Beer]

Hi Richard,


Thank you for the additional information it is very useful. I can no longer see the subm:rtp_topic after the last crash with the HEP modules disabled. This will hopefully resolve that issue, however, I've just seen the following SIGSEGV issue:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f1ee50edda0 in pj_pool_release () from /lib64/libpj.so.2
[Current thread is 1 (Thread 0x7f1ed3de4700 (LWP 31442))]
#0  0x00007f1ee50edda0 in pj_pool_release () at /lib64/libpj.so.2
#1  0x00007f1ee6c32b48 in pjsip_tx_data_dec_ref () at /lib64/libpjsip.so.2
#2  0x00007f1ee6c32d60 in pjsip_transport_send () at /lib64/libpjsip.so.2
#3  0x00007f1ee6c3e6be in tsx_send_msg () at /lib64/libpjsip.so.2
#4  0x00007f1ee6c3e227 in tsx_timer_callback () at /lib64/libpjsip.so.2
#5  0x00007f1ee50f63b7 in pj_timer_heap_poll () at /lib64/libpj.so.2
#6  0x00007f1ee6c2dc3b in pjsip_endpt_handle_events2 () at /lib64/libpjsip.so.2
#7  0x00007f1ed58c7508 in monitor_thread_exec (endpt=<optimized out>) at res_pjsip.c:3863
        delay = {sec = 0, msec = 10}
#8  0x00007f1ee50e7a56 in thread_main () at /lib64/libpj.so.2
#9  0x00007f1f66ad261a in start_thread () at /lib64/libpthread.so.0
#10 0x00007f1f65e0e59d in clone () at /lib64/libc.so.6

Should another issue be raised for this?

Kind regards,

Ross



________________________________
From: asterisk-dev-bounces at lists.digium.com <asterisk-dev-bounces at lists.digium.com> on behalf of Richard Mudgett <rmudgett at digium.com>
Sent: 28 June 2016 17:00
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] ASTERISK-26145 - Task Process Issues possibly caused by HEP



On Tue, Jun 28, 2016 at 10:20 AM, Ross Beer <ross.beer at outlook.com<mailto:ross.beer at outlook.com>> wrote:

Hi,


I agree that the conversation about HEP default settings doesn't warrant a lengthy discussion, however, the fact that the 'task processor' causes asterisk to stop processing packets is a serious issue. This is happening multiple times a day on several boxes.


I'm trying to identify what is causing over 1500 tasks to back-up in the 'subm:rtp_topic-000000de' scheduler. This is proving difficult as you only see counts and not actual waiting tasks.

The res_hep_rtcp.so module is what creates the subm:rtp_topic stasis message bus subscription.  Since you have indicated that you are not using that feature you should not load the module.

The taskprocessors that begin with 'subm:' (m for mailbox) or 'subp:' (p for thread pool) are stasis message bus subscriptions.  The 'subm:' taskprocessors have a single dedicated thread to process the taskprocessor tasks.  The 'subp:' taskprocessors do not have a dedicated thread.  Those taskprocessors get executed by an available thread from the stasis thread pool.  The stasis thread pool is configured by the stasis.conf file.

Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160628/499d0cb4/attachment.html>