[asterisk-bugs] [JIRA] (ASTERISK-30482) AudioSocket: Lack of wait in loop causing high CPU usage

Asterisk Team (JIRA) noreply at issues.asterisk.org
Sat Apr 1 04:09:03 CDT 2023


    [ https://issues.asterisk.org/jira/browse/ASTERISK-30482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=261677#comment-261677 ] 

Asterisk Team commented on ASTERISK-30482:
------------------------------------------

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. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

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].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].

> AudioSocket: Lack of wait in loop causing high CPU usage
> --------------------------------------------------------
>
>                 Key: ASTERISK-30482
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30482
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/General
>    Affects Versions: 18.0.0
>         Environment: Linux asterisk-vm 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux running in Oracle VirtualBox.
>            Reporter: Ross
>
> Hi, I have become aware of bug in the recently added AudioSocket functionality of Astierks 18 and above. The issue is specific to the dialplan app variant of the feature and occurs on exactly [this line in apps/app_audiosocket.c|https://github.com/asterisk/asterisk/blob/edd7f1b0605e2840b2e21bf45afa67950dd3f9fe/apps/app_audiosocket.c#L184]. It is caused by a value of 0 being passed as the "ms" parameter to the "ast_waitfor_nandfds()" function. Since this function seems to eventually invoke the underlying OS's "poll()" implementation, the function never actually waits for activity and the loop it resides in runs as fast as possible, usually causesing a single core to reach 100% utilization. 
> My personal idea for it's solution was to pass a hard-coded 2000 milliseconds instead, as 2 seconds seemed like a reasonable time to wait for activity to occur on either end (and it was also the timeout value for the initial server "connect()" call).
> Also, while I don't know how much of a part this played in the mistake being made, I noticed that [the documentation for the function "ast_waitfor_nandfds()"|https://github.com/asterisk/asterisk/blob/edd7f1b0605e2840b2e21bf45afa67950dd3f9fe/include/asterisk/channel.h#L1992] doesn't mention that the "ms" parameter is an *in* parameter too, determining how long the wait will be as well as how long it _was_. 
> I know that support for AudioSocket is under the status of "Community", and I have fixed this rather trivial issue myself, but more importantly I feel, I also cleaned up and fixed a lot of other issues present its code. More specifically, fixing the un-clean app exit issue mentioned [here|https://issues.asterisk.org/jira/browse/ASTERISK-30227], improving logging/error messages, decreasing the number of calls to "read()", shortening the code in general and replacing some of the  programming-tricks with potentially cleaner methods (removing pointer arithmetic, using "htons()" instead of direct bit shifting for endieness swapping). However, I'm not sure of the best way to submit these (all at once or splitting them up) as I just performed them as I worked in my testing environment.
> Thank you



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list