| Summary: | ASTERISK-27417: Endpoints not getting registered | ||||
| Reporter: | shaurya jain (shaurya) | Labels: | |||
| Date Opened: | 2017-11-14 06:38:56.000-0600 | Date Closed: | 2020-01-14 11:13:29.000-0600 | ||
| Priority: | Critical | Regression? | |||
| Status: | Closed/Complete | Components: | pjproject/pjsip | ||
| Versions: | 13.18.2 | Frequency of Occurrence | Frequent | ||
| Related Issues: |
| ||||
| Environment: | Ubuntu 16.04,PJSIP_2.6,webrtc | Attachments: | ( 0) core_show_channels_concise.txt ( 1) core_show_taskprocessors.txt ( 2) ERROR_logs.txt ( 3) sterling.txt | ||
| Description: | Endpoints were not getting registered after the attached error,and after that we need to restart the asterisk to make the things working.
Attached are the GDB and other relevant logs, | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2017-11-14 06:38:57.449-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: shaurya jain (shaurya) 2017-11-14 06:40:21.899-0600 PFA By: Richard Mudgett (rmudgett) 2017-11-14 11:47:17.671-0600 You appear to have a deadlock associated with res_hep_rtcp.c. [^core_show_taskprocessors.txt] shows that {{subm:rtp_topic-000000cc}} is blocked from processing messages in its queue. This is why {{subm:rtp_topic-000000cc}} shows a large number of tasks in its queue but the max queue depth is lower. Thread 62 is the dedicated thread processing {{subm:rtp_topic-000000cc}}. That thread is waiting on Thread 84 which is handling the session serializer to process the request. Thread 84 is blocked waiting for a bridge lock. However, I am not able to find which thread is holding the bridge lock to continue the blocking chain. You need to enable DEBUG_THREADS in menuselect [1][2] to enable lock tracking. [1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace [2] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock Also, if you don't need the Homer (HEPv3 logger) functionality you shouldn't load the res_hep* modules as it seems to be triggering your deadlock. By: shaurya jain (shaurya) 2017-11-15 01:00:42.796-0600 Dear Richard , I have unload below modules,will update the status after today's calling. noload => res_hep.so noload => res_hep_pjsip.so noload => res_hep_rtcp.so Also,We can not enable debug threads as we paced 25 calls per second and enabling debug threads may increase load on the server. Regards, Shaurya Jain By: Richard Mudgett (rmudgett) 2017-11-15 12:16:56.095-0600 Still awaiting better information. By: Aaron An (aaron) 2017-11-21 08:39:52.390-0600 noload hep related modules didn't solve this issue. It is something wrong with the alertpipe read(). There are huge amount of Bad file descriptor WARNING. [Nov 21 16:43:20] WARNING[27819][C-00014acc] alertpipe.c: read() failed: Bad file descriptor [Nov 21 16:43:20] WARNING[27819][C-00014acc] alertpipe.c: read() failed: Bad file descriptor [Nov 21 16:43:20] WARNING[27819][C-00014acc] alertpipe.c: read() failed: Bad file descriptor [Nov 21 16:43:20] WARNING[27819][C-00014acc] alertpipe.c: read() failed: Bad file descriptor By: Asterisk Team (asteriskteam) 2017-12-05 12:00:01.832-0600 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines | ||||