Summary: | ASTERISK-25416: pbx_dundi: Using scheduler context after deletion | ||
Reporter: | Birger "WIMPy" Harzenetter (wimpy) | Labels: | |
Date Opened: | 2015-09-24 01:04:56 | Date Closed: | |
Priority: | Minor | Regression? | Yes |
Status: | Open/New | Components: | PBX/pbx_dundi |
Versions: | 11.19.0 13.18.4 | Frequency of Occurrence | Occasional |
Related Issues: | |||
Environment: | Attachments: | ( 0) Asterisk-debug.txt | |
Description: | Asterisk locks up when performing a "core restart when convenient"
[edit by Rusty - below] For reference, [Asterisk-debug.txt|https://issues.asterisk.org/jira/secure/attachment/53023/Asterisk-debug.txt] contains: * Backtrace * 'core show locks' output * 'core show threads' output * 'core show taskprocessors' output | ||
Comments: | By: Asterisk Team (asteriskteam) 2015-09-24 01:04:58.490-0500 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: Rusty Newton (rnewton) 2015-09-30 14:48:23.034-0500 The debug may be enough, but do you have a configuration that makes it easy to reproduce this locking scenario? It is always useful for testing fixes if we can reproduce the scenario. Thanks! By: Birger "WIMPy" Harzenetter (wimpy) 2015-09-30 17:41:25.762-0500 It has happened before, but most of the time it restarts as expected. So, no easy way to reproduce. By: Mark Michelson (mmichelson) 2015-10-01 15:32:55.536-0500 The problem appears to be that pbx_dundi destroys its scheduler context but then tries to access it again later when pruning peers. In some cases, this will go fine since the recently destroyed object will still be usable. However, it is possible for the memory where the destroyed object resides to have been overwritten with something new, thereby trying to operate the lock useless. It's in these cases that the shutdown blocks forever. The proper solution here is to destroy the scheduler context after pruning peers in pbx_dundi's unload_module() function. |