ASTERISK-25416: pbx_dundi: Using scheduler context after deletion

[Home]

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.