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: [email protected]
<[email protected]> on behalf of Richard Mudgett
<[email protected]>
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
<[email protected]<mailto:[email protected]>> 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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
