<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/1526/">https://reviewboard.asterisk.org/r/1526/</a>
</td>
</tr>
</table>
<br />
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers and kmoore.</div>
<div>By mjordan.</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">A number of subtle errors were detected through ASTERISK-18135.
When an extension is removed from a context, its entry in the pattern matching tree is not deleted. Instead, the extension is marked as deleted. When an extension is removed (marked as deleted) and readded, if that extension is a prefix of another extension, several log messages did not check to see if the extension was deleted before printing out the extension. This would cause an invalid read access.
In addition, if the extension was already in the tree (but deleted) and the pattern was at an end, the findonly flag was not honored and the extension would be erroneously undeleted.
Finally, during testing, it was discovered that an IAX2 peer could be unregistered via the CLI, while at the same time it could be scheduled for unregistration. The unregistration method now checks to see if something else (such as the CLI) has already unregistered the IAX2 peer before it performs the unregistration.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Performed the scenario described in ASTERISK-18135 under valgrind; this patch did indeed resolve the memory access issues.
Also tested with SIP peers; ran under the Asterisk test suite without issues.</pre>
</td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-18135">ASTERISK-18135</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/branches/1.8/channels/chan_iax2.c <span style="color: grey">(340930)</span></li>
<li>/branches/1.8/main/pbx.c <span style="color: grey">(340930)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/1526/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>