<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/2086/">https://reviewboard.asterisk.org/r/2086/</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.</div>
<div>By Mark Michelson.</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;">In ASTERISK-20305, a crash was reported in app_page that stemmed from the use of an uninitialized aco_type pointer by app_confbridge. The reason that the pointer was uninitialized was that app_confbridge had failed to load due to a missing confbridge.conf file. Even though app_confbridge had not loaded, the CONFBRIDGE dialplan function was still accessible from app_page.
This patch fixes the problem in two ways:
1) The actual crash is fixed by mending config_options.c not to assume that aco_type->internal and aco_info->internal are allocated/initialized. Since it is possible to call aco functions with invalid data, we need to be prepared for it.
2) app_confbridge's dialplan functions, dialplan applications, and manager actions do not need to stay registered if the module declines to load. The simple fix for this was to place the one condition under which the module could decline loading at the top of the load_module() function.
It should be noted that app_confbridge is almost certainly not the only app that registers applications, funtions, and manager actions and fails to unregister them when the module declines loading. I will be opening up an issue report soon to get this taken care of across the board.</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;">I ran the reporter of ASTERISK-20305's test:
1) Start Asterisk with no confbridge.conf file
2) Run app_page.
Prior to this set of fixes, this would crash.
I also ran another test the reporter mentioned:
1) Start Asterisk with no confbridge.conf file
2) Create a confbridge.conf file
3) run "module load app_confbridge.so" from the Asterisk CLI
Prior to this set of fixes, the "module load" would fail because the dialplan function "CONFBRIDGE" was already registered. With this set of changes, the module loads as expected now.</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-20305">ASTERISK-20305</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/11/apps/app_confbridge.c <span style="color: grey">(371779)</span></li>
<li>/branches/11/main/config_options.c <span style="color: grey">(371779)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/2086/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>