<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/4247/">https://reviewboard.asterisk.org/r/4247/</a>
     </td>
    </tr>
   </table>
   <br />










<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On December 10th, 2014, 4:38 p.m. CST, <b>Mark Michelson</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  



<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
 <thead>
  <tr>
   <th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
    <a href="https://reviewboard.asterisk.org/r/4247/diff/3/?file=69606#file69606line135" style="color: black; font-weight: bold; text-decoration: underline;">/branches/1.8/main/lock.c</a>
    <span style="font-weight: normal;">

     (Diff revision 3)

    </span>
   </th>
  </tr>
 </thead>

 <tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
  <tr>

   <td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">static void __dump_backtrace(struct ast_bt *bt, int canlog)</pre></td>

  </tr>
 </tbody>



 
 

 <tbody>

  <tr>
    <th bgcolor="#e9eaa8" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2">75</font></th>
    <td bgcolor="#fdfebc" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="cm">/*</span></pre></td>
    <th bgcolor="#e9eaa8" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">134</font></th>
    <td bgcolor="#fdfebc" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb">   </span><span class="tb">  </span><span class="kt">int</span> <span class="n">canlog</span> <span class="o">=</span> <span class="n">tracking</span> <span class="o">&&</span> <span class="n">strcmp</span><span class="p">(</span><span class="n">filename</span><span class="p">,</span> <span class="s">"logger.c"</span><span class="p">);</span></pre></td>
  </tr>

 </tbody>

</table>

  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">canlog appears to be unused here.

In fact, the places where canlog ends up being used, it's not used. What I mean is that a canlog value is determined, then it's passed to __dump_backtrace(), which doesn't actually use the canlog parameter for anything.</pre>
 </blockquote>



 <p>On December 10th, 2014, 4:56 p.m. CST, <b>rmudgett</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">canlog is actually used indirectly by the __ast_mutex_logger() macro.  A bad thing to do it since the use is hidden, but its very old legacy code.</pre>
 </blockquote>





 <p>On December 11th, 2014, 9:43 a.m. CST, <b>Mark Michelson</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">That is just awful *barfy face*</pre>
 </blockquote>







</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I enjoyed the use of *barfy face* to describe this code.

(Funny side story: the only reason I didn't put this same finding on here was because I attempted to "clean up" this code awhile back and got hit in the face with undefined references from said macro. I then died a little bit on the inside. In the end, the "clean up" was an abysmal failure.)</pre>
<br />




<p>- Matt</p>


<br />
<p>On December 9th, 2014, 11:21 a.m. CST, rmudgett wrote:</p>








<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Asterisk Developers.</div>
<div>By rmudgett.</div>


<p style="color: grey;"><i>Updated Dec. 9, 2014, 11:21 a.m.</i></p>







<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-19463">ASTERISK-19463</a>, 

 <a href="https://issues.asterisk.org/jira/browse/ASTERISK-22455">ASTERISK-22455</a>


</div>



<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt;">Repository: </b>
Asterisk
</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;">This patch started with David Lee's patch at
https://reviewboard.asterisk.org/r/2826/ and includes a regression fix
introduced by the ASTERISK-22455 patch.

The initialization of a mutex's lock tracking structure was not protected
in a critical section.  This is fine for any mutex that is explicitly
initialized, but a static mutex may have its lock tracking double
initialized if multiple threads attempt the first lock simultaneously.

* Added a global mutex to properly serialize initialization of the lock
tracking structure.  The painful global lock can be mitigated by adding a
double checked lock flag as discussed on the original review request.

* Defer lock tracking initialization until first use.

* Don't be "helpful" and initialize an uninitialized lock when
DEBUG_THREADS is enabled.  Debug code is not supposed to fix or change
normal code behavior.  We don't need a lock initialization race that would
force a re-setup of lock tracking.  Lock tracking already handles
initialization on first use.

* Properly handle allocation failures of the lock tracking structure.

* No need to initialize tracking data in __ast_pthread_mutex_destroy()
just to turn around and destroy it.


The regression introduced by ASTERISK-22455 is the result of manipulating
a pthread_mutex_t struct outside of the pthread library code.  The
pthread_mutex_t struct seems to have a global linked list pointer member
that can get changed by other threads.  Therefore, saving and restoring
the contents of a pthread_mutex_t struct is a bad thing.

Thanks to Thomas Airmont for finding this obscure regression.

* Don't overwrite the struct ast_lock_track.reentr_mutex member to restore
tracking data in __ast_cond_wait() and __ast_cond_timedwait().  The
pthread_mutex_t struct must be treated as a read-only opaque variable.


Miscellaneous other items fixed by this patch:

* Match ast_suspend_lock_info() with ast_restore_lock_info() in
__ast_cond_timedwait().

* Made some uninitialized lock sanity checks return EINVAL and try a
DO_THREAD_CRASH.

* Fix bad canlog initialization expressions.


NOTE: The first diff on this review is the unmodified
https://reviewboard.asterisk.org/r/2826/ patch for comparison with the
updated patch.
</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;">Without the patch on v1.8, I repeatedly ran the testsuite masquerade
supertest and it died an hour or two later.  With the patch, it ran over
the weekend without a problem.

Since the DEBUG_THREADS locking issues on Asterisk startup
(ASTERISK-19463) have been a hard problem to reproduce, I propose we setup
Bamboo to run the TestSuite with DEBUG_THREADS enabled on the
http://svn.asterisk.org/svn/asterisk/team/rmudgett/debug_threads branch
nightly for a few weeks.
</pre>
  </td>
 </tr>
</table>


<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/main/lock.c <span style="color: grey">(429174)</span></li>

 <li>/branches/1.8/include/asterisk/lock.h <span style="color: grey">(429174)</span></li>

</ul>

<p><a href="https://reviewboard.asterisk.org/r/4247/diff/" style="margin-left: 3em;">View Diff</a></p>







  </td>
 </tr>
</table>








  </div>
 </body>
</html>