<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <div class="moz-cite-prefix">El 10/04/15 a las 14:16, Alex Villacís

      Lasso escribió:<br>

    </div>

    <blockquote cite="mid:55282195.7060505@palosanto.com" type="cite">

      <meta content="text/html; charset=windows-1252"

        http-equiv="Content-Type">

      <div class="moz-cite-prefix">El 08/04/15 a las 08:22, Vinicius

        Fontes escribió:<br>

      </div>

      <blockquote

cite="mid:CAP_GNRmwWN2UNQRdHh950wuuhUB05ZF9vOumN8Uovbr79dv73A@mail.gmail.com"

        type="cite">

        <div dir="ltr">Have you tried Asterisk 13? The bridging

          mechanism has been completely rewritten on Asterisk 12, so

          there's no longer channel masquerading and zombie channels.

          Might be worth a try.</div>

        <div class="gmail_extra"><br>

        </div>

      </blockquote>

      Sorry, this client is very hard to talk into stopping its

      operations long enough to install changes, let alone a major

      Asterisk version change. I already had trouble convincing him of

      the need to install a debugging version with DEBUG_THREADS

      enabled.<br>

    </blockquote>

    After reviewing a "core show locks" output, I am very sure I have

    hit an Asterisk bug involving a deadlock in cdr_mysql . When doing a

    "core reload" on the CLI, cdr_mysql calls ast_cdr_unregister() with

    its internal lock held (mysql_lock). However, writing a CDR involves

    adquiring the cdr lock and then the internal lock. Therefore,

    deadlock. None of the other cdr modules does that.<br>

    <br>

    However, I know that cdr_mysql is currently deprecated for Asterisk

    11. I have a patch to fix the issue mentioned above (attached), but

    I want to know how to get it reviewed, if only to see whether the

    fix is sane.<br>

  </body>

</html>