<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    I found some cases when variables were not freed, but I cannot test
    as I am not using unixodbc.<br>
    <br>
    Can you cherry pick the patch:<br>
    <br>
    -
<a class="moz-txt-link-freetext" href="http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=edc78dfb148c22f0d256485193bbdb0185b76d2f">http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=edc78dfb148c22f0d256485193bbdb0185b76d2f</a><br>
    <br>
    and see if not all goes ok? If not other issues, then I will
    backport.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    <div class="moz-cite-prefix">On 21/03/14 17:37, Alex Villací­s Lasso
      wrote:<br>
    </div>
    <blockquote cite="mid:532C6AD8.3040504@palosanto.com" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <div class="moz-text-flowed" style="font-family: -moz-fixed;
        font-size: 14px;" lang="x-western">I have a CentOS 6
        installation with the following packages installed from the RPM
        build service from Kamailio: <br>
        <br>
        kamailio-unixodbc-4.1.2-1.1.x86_64 <br>
        kamailio-4.1.2-1.1.x86_64 <br>
        kamailio-presence-4.1.2-1.1.x86_64 <br>
        kamailio-utils-4.1.2-1.1.x86_64 <br>
        <br>
        I am also using db_unixodbc for all database accesses (with
        MySQL backend). The problem is that after a few hours, a single
        Kamailio process (never more than one) starts complaining that
        it has run out of memory: <br>
        <br>
         9(11479) ERROR: uac [uac_reg.c:638]: uac_reg_tm_callback(): got
        sip response 408 while registering [admin_pbx.elastix.com] <br>
         9(11479) ERROR: db_unixodbc [dbase.c:335]:
        db_unixodbc_fetch_result(): no memory left <br>
         9(11479) ERROR: <core> [db_query.c:502]: db_fetch_next():
        unable to fetch next rows <br>
         9(11479) ERROR: db_unixodbc [dbase.c:224]:
        db_unixodbc_free_result(): invalid parameter value <br>
         9(11479) ERROR: db_unixodbc [dbase.c:327]:
        db_unixodbc_fetch_result(): no private memory left <br>
         9(11479) ERROR: <core> [db_query.c:434]:
        db_fetch_query_internal(): unable to fetch the db result <br>
         9(11479) ERROR: presence [publish.c:108]:
        msg_presentity_clean(): failed to query database for expired
        messages <br>
         9(11479) ERROR: db_unixodbc [dbase.c:327]:
        db_unixodbc_fetch_result(): no private memory left <br>
         9(11479) ERROR: <core> [db_query.c:434]:
        db_fetch_query_internal(): unable to fetch the db result <br>
         9(11479) ERROR: presence [publish.c:108]:
        msg_presentity_clean(): failed to query database for expired
        messages <br>
         9(11479) ERROR: db_unixodbc [dbase.c:327]:
        db_unixodbc_fetch_result(): no private memory left <br>
         9(11479) ERROR: <core> [db_query.c:434]:
        db_fetch_query_internal(): unable to fetch the db result <br>
        <br>
        I have attached the stderr output when I kill the offending
        process. From what I can see, the memory leak somehow involves
        database allocations that fail to be freed, consuming more than
        3 MB out of 4 MB allocated: <br>
        <br>
         9(11479) NOTICE: <core> [main.c:857]: sig_usr(): Memory
        still-in-use summary (pkg): <br>
         9(11479) NOTICE: qm_sums: summarizing all alloc'ed. fragments:
        <br>
         9(11479) NOTICE: qm_sums:  count=     1 size=     10240 bytes
        from mi_fifo: mi_writer.c: mi_writer_init(57) <br>
         9(11479) NOTICE: qm_sums:  count=   378 size=   3029384 bytes
        from db_unixodbc: dbase.c: db_unixodbc_fetch_result(333) <br>
         9(11479) NOTICE: qm_sums:  count=     1 size=      4096 bytes
        from db_unixodbc: dbase.c: db_unixodbc_fetch_result(325) <br>
         9(11479) NOTICE: qm_sums:  count=     1 size=        16 bytes
        from <core>: sr_module.c: init_modules(1002) <br>
         9(11479) NOTICE: qm_sums:  count=     1 size=        56 bytes
        from textops: textops.c: hname_fixup(1634) <br>
         9(11479) NOTICE: qm_sums:  count=     1 size=        32 bytes
        from rr: rr_cb.c: register_rrcb(63) <br>
        <br>
        I have the setup to compile my own RPMS, and I intend to track
        down the memory leak on my own. However, I would like your help
        in focusing my search, on whether this is a known issue, or
        where in db_unixodbc should I look. <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio World Conference - April 2-4, 2014, Berlin, Germany
<a class="moz-txt-link-freetext" href="http://www.kamailioworld.com">http://www.kamailioworld.com</a></pre>
  </body>
</html>