sig_analog: Fix channel leak when mwimonitor is enabled.#459
Merged
asterisk-org-access-app[bot] merged 1 commit intoNov 28, 2023
Merged
Conversation
Contributor
Author
|
cherry-pick-to: 18 |
seanbright
reviewed
Nov 24, 2023
fa08274 to
0c45730
Compare
seanbright
reviewed
Nov 28, 2023
When mwimonitor=yes is enabled for an FXO port, the do_monitor thread will launch mwi_thread if it thinks there could be MWI on an FXO channel, due to the noise threshold being satisfied. This, in turns, calls analog_ss_thread_start in sig_analog. However, unlike all other instances where __analog_ss_thread is called in sig_analog, this call path does not properly set pvt->ss_astchan to the Asterisk channel, which means that the Asterisk channel is NULL when __analog_ss_thread starts executing. As a result, the thread exits and the channel is never properly cleaned up by calling ast_hangup. This caused issues with do_monitor on incoming calls, as it would think the channel was still owned even while receiving events, leading to an infinite barrage of warning messages; additionally, the channel would persist improperly. To fix this, the assignment is added to the call path where it is missing (which is only used for mwi_thread). A warning message is also added since previously there was no indication that __analog_ss_thread was exiting abnormally. This resolves both the channel leak and the condition that led to the warning messages. Resolves: asterisk#458
0c45730 to
ebdb12c
Compare
seanbright
approved these changes
Nov 28, 2023
jcolp
approved these changes
Nov 28, 2023
|
Successfully merged to branch master and cherry-picked to ["18","20","21"] |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When mwimonitor=yes is enabled for an FXO port,
the do_monitor thread will launch mwi_thread if it thinks there could be MWI on an FXO channel, due to the noise threshold being satisfied. This, in turns, calls
analog_ss_thread_start in sig_analog. However, unlike all other instances where __analog_ss_thread is called in sig_analog, this call path does not properly set pvt->ss_astchan to the Asterisk channel, which means that the Asterisk channel is NULL when __analog_ss_thread starts executing. As a result, the thread exits and the channel is never properly cleaned up by calling ast_hangup.
This caused issues with do_monitor on incoming calls, as it would think the channel was still owned even while receiving events, leading to an infinite barrage of warning messages; additionally, the channel would persist improperly.
To fix this, the assignment is added to the call path where it is missing (which is only used for mwi_thread). A warning message is also added since previously there was no indication that __analog_ss_thread was exiting abnormally. This resolves both the channel leak and the condition that led to the warning messages.
Resolves: #458