app_rpt: Correct crash when using rpt page #377
Merged
Conversation
This file contains 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
This updates app_rpt to address a crash that occurred when using the rpt page command. ast_sendtext should not require locking according to the documentation, but that does not seem to be the case. In some instances, the main processing loop had control of the channel. ast_sendtext would cause an assert abort in channel.c. This was shown by the message ast_sendtext_data: Thread LWP 88692 is blocking 'Radio/usb_2231', already blocked by thread LWP 88688 in procedure ast_waitfor_nandfds. Adding rpt_mutex_lock around ast_sendtext resolved the problem. Corrected an if statement in the same routine that was already flagged in the code as a bug. Applied coding standards to the routine. This closes #375.
This updates app_rpt to address a crash that occurred when using the rpt page command. ast_sendtext should not require locking according to the documentation, but that does not seem to be the case. In some instances, the main processing loop had control of the channel. ast_sendtext would cause an assert abort in channel.c. This was shown by the message ast_sendtext_data: Thread LWP 88692 is blocking 'Radio/usb_2231', already blocked by thread LWP 88688 in procedure ast_waitfor_nandfds. Adding rpt_mutex_lock around ast_sendtext resolved the problem. Corrected an if statement in the same routine that was already flagged in the code as a bug. Remove chan_usbradio as a destination for paging. chan_usbradio does not implement paging. Sending pages to chan_usbradio resulted in a stuck PTT. Applied coding standards to the routine. This closes #375 and #371.
Allan-N
approved these changes
Aug 12, 2024
|
On 08/10 (on slack), I asked @InterLinked1 about this change and the usage of &myrpt->blocklock. He replied with : I had taken a look at work earlier this week but forgot to respond, the PR looks good to me. Asterisk does recursive locking (not normally enabled by default in pthreads) so the same thread can acquire a lock multiple times. I don't really like that idea personally but it's commonplace in Asterisk so a perfectly okay thing to do here. |
InterLinked1
approved these changes
Sep 12, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This updates app_rpt to address a crash that occurred when using the rpt page command.
ast_sendtext should not require locking according to the documentation, but that does not seem to be the case. In some instances, the main processing loop had control of the channel. ast_sendtext would cause an assert abort in channel.c.
This was shown by the message ast_sendtext_data: Thread LWP 88692 is blocking 'Radio/usb_2231', already blocked by thread LWP 88688 in procedure ast_waitfor_nandfds.
Adding rpt_mutex_lock around ast_sendtext resolved the problem.
Corrected an if statement in the same routine that was already flagged in the code as a bug.
Remove chan_usbradio as a destination for paging. chan_usbradio does not implement paging. Sending pages to chan_usbradio resulted in a stuck PTT.
Applied coding standards to the routine.
This closes #375 and #371.