<p>I've restricted memcheck to pkg only, and also benefited from the "red zone" feature of memcheck: an empty zone between each chunk that will trigger an error in memcheck if it's accessed. This way, it's easier to catch a memory error exactly when it happens.<br>
Executing this code (new function in the <strong>malloc_test</strong> module):</p>
<div class="highlight highlight-source-c"><pre><span class="pl-k">static</span> <span class="pl-k">int</span> <span class="pl-en">mt_pkg_overflow_f</span>(<span class="pl-k">struct</span> sip_msg* msg, <span class="pl-k">char</span> *p1,<span class="pl-k">char</span> *p2) {
        <span class="pl-k">int</span> i;
        <span class="pl-k">unsigned</span> <span class="pl-k">long</span> *a;

        a = <span class="pl-c1">pkg_malloc</span>(<span class="pl-c1">1024</span> * <span class="pl-k">sizeof</span>(<span class="pl-k">unsigned</span> <span class="pl-k">long</span>));

        <span class="pl-k">if</span> (!a) {
                <span class="pl-c1">LM_ERR</span>(<span class="pl-s"><span class="pl-pds">"</span>no more pkg<span class="pl-cce">\n</span><span class="pl-pds">"</span></span>);
                <span class="pl-k">return</span> -<span class="pl-c1">1</span>;
        }

        *(a - <span class="pl-c1">1</span>) = 0xdeadbeef;
        *(a + <span class="pl-c1">1024</span>) = 0xdeadc0de;
        <span class="pl-k">for</span> (i = <span class="pl-c1">0</span> ; i < <span class="pl-c1">1024</span>; i++) {
                a[i] = (<span class="pl-k">long</span>)i;
        }

        <span class="pl-k">return</span> <span class="pl-c1">1</span>;
}</pre></div>
<p>immediately triggers these errors:</p>
<pre><code>==56832== Invalid write of size 8
==56832==    at 0x93E1CD1: mt_pkg_overflow_f (malloc_test.c:689)
==56832==    by 0x456E8B: do_action (action.c:1054)
==56832==    by 0x463590: run_actions (action.c:1552)
==56832==    by 0x463CFD: run_top_route (action.c:1641)
==56832==    by 0x589484: receive_msg (receive.c:264)
==56832==    by 0x49BDFC: receive_tcp_msg (tcp_read.c:1230)
==56832==    by 0x49E0EB: tcp_read_req (tcp_read.c:1445)
==56832==    by 0x4A0CB6: handle_io (tcp_read.c:1619)
==56832==    by 0x493237: io_wait_loop_epoll (io_wait.h:1065)
==56832==    by 0x4A2B05: tcp_receive_loop (tcp_read.c:1789)
==56832==    by 0x509C52: tcp_init_children (tcp_main.c:4796)
==56832==    by 0x423465: main_loop (main.c:1708)
==56832==  Address 0x56d6fc8 is 632,184 bytes inside a fragment data (init) of size 8,119,728 client-defined
==56832==    at 0x64E1EB: qm_malloc_init (q_malloc.c:261)
==56832==    by 0x6584E7: qm_malloc_init_pkg_manager (q_malloc.c:1117)
==56832==    by 0x642A23: pkg_init_manager (pkg.c:68)
==56832==    by 0x4244FD: main (main.c:1931)
==56832== 
==56832== Invalid write of size 8
==56832==    at 0x93E1CE3: mt_pkg_overflow_f (malloc_test.c:690)
==56832==    by 0x456E8B: do_action (action.c:1054)
==56832==    by 0x463590: run_actions (action.c:1552)
==56832==    by 0x463CFD: run_top_route (action.c:1641)
==56832==    by 0x589484: receive_msg (receive.c:264)
==56832==    by 0x49BDFC: receive_tcp_msg (tcp_read.c:1230)
==56832==    by 0x49E0EB: tcp_read_req (tcp_read.c:1445)
==56832==    by 0x4A0CB6: handle_io (tcp_read.c:1619)
==56832==    by 0x493237: io_wait_loop_epoll (io_wait.h:1065)
==56832==    by 0x4A2B05: tcp_receive_loop (tcp_read.c:1789)
==56832==    by 0x509C52: tcp_init_children (tcp_main.c:4796)
==56832==    by 0x423465: main_loop (main.c:1708)
==56832==  Address 0x56d8fd0 is 640,384 bytes inside a fragment data (init) of size 8,119,728 client-defined
==56832==    at 0x64E1EB: qm_malloc_init (q_malloc.c:261)
==56832==    by 0x6584E7: qm_malloc_init_pkg_manager (q_malloc.c:1117)
==56832==    by 0x642A23: pkg_init_manager (pkg.c:68)
==56832==    by 0x4244FD: main (main.c:1931)
</code></pre>
<p>The custom naming of the blocks ("fragment data") and the offset reported do not work as I expect: I'd expect the fist error to happen in a block named "fragment header" at its end and the last one in "fragment data" at its end too, so either my expectations are wrong or my code is.</p>
<p>Also I did not cover the instrumentation of the memory join code yet, so this should only be correct when <strong>mem_join=0</strong>.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/kamailio/kamailio/issues/949#issuecomment-283141244">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AF36ZZP27hzZlWco01KiqpTd0hg4rqBVks5rhHhNgaJpZM4LuZds">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AF36ZS_XFWkInF2s30NIriKxFCUADw0xks5rhHhNgaJpZM4LuZds.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/kamailio/kamailio/issues/949#issuecomment-283141244"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/kamailio/kamailio","title":"kamailio/kamailio","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/kamailio/kamailio"}},"updates":{"snippets":[{"icon":"PERSON","message":"@camilleoudot in #949: I've restricted memcheck to pkg only, and also benefited from the \"red zone\" feature of memcheck: an empty zone between each chunk that will trigger an error in memcheck if it's accessed. This way, it's easier to catch a memory error exactly when it happens.\r\nExecuting this code (new function in the **malloc_test** module):\r\n```C\r\nstatic int mt_pkg_overflow_f(struct sip_msg* msg, char *p1,char *p2) {\r\n\tint i;\r\n\tunsigned long *a;\r\n\r\n\ta = pkg_malloc(1024 * sizeof(unsigned long));\r\n\r\n\tif (!a) {\r\n\t\tLM_ERR(\"no more pkg\\n\");\r\n\t\treturn -1;\r\n\t}\r\n\r\n\t*(a - 1) = 0xdeadbeef;\r\n\t*(a + 1024) = 0xdeadc0de;\r\n\tfor (i = 0 ; i \u003c 1024; i++) {\r\n\t\ta[i] = (long)i;\r\n\t}\r\n\r\n\treturn 1;\r\n}\r\n```\r\nimmediately triggers these errors:\r\n```\r\n==56832== Invalid write of size 8\r\n==56832==    at 0x93E1CD1: mt_pkg_overflow_f (malloc_test.c:689)\r\n==56832==    by 0x456E8B: do_action (action.c:1054)\r\n==56832==    by 0x463590: run_actions (action.c:1552)\r\n==56832==    by 0x463CFD: run_top_route (action.c:1641)\r\n==56832==    by 0x589484: receive_msg (receive.c:264)\r\n==56832==    by 0x49BDFC: receive_tcp_msg (tcp_read.c:1230)\r\n==56832==    by 0x49E0EB: tcp_read_req (tcp_read.c:1445)\r\n==56832==    by 0x4A0CB6: handle_io (tcp_read.c:1619)\r\n==56832==    by 0x493237: io_wait_loop_epoll (io_wait.h:1065)\r\n==56832==    by 0x4A2B05: tcp_receive_loop (tcp_read.c:1789)\r\n==56832==    by 0x509C52: tcp_init_children (tcp_main.c:4796)\r\n==56832==    by 0x423465: main_loop (main.c:1708)\r\n==56832==  Address 0x56d6fc8 is 632,184 bytes inside a fragment data (init) of size 8,119,728 client-defined\r\n==56832==    at 0x64E1EB: qm_malloc_init (q_malloc.c:261)\r\n==56832==    by 0x6584E7: qm_malloc_init_pkg_manager (q_malloc.c:1117)\r\n==56832==    by 0x642A23: pkg_init_manager (pkg.c:68)\r\n==56832==    by 0x4244FD: main (main.c:1931)\r\n==56832== \r\n==56832== Invalid write of size 8\r\n==56832==    at 0x93E1CE3: mt_pkg_overflow_f (malloc_test.c:690)\r\n==56832==    by 0x456E8B: do_action (action.c:1054)\r\n==56832==    by 0x463590: run_actions (action.c:1552)\r\n==56832==    by 0x463CFD: run_top_route (action.c:1641)\r\n==56832==    by 0x589484: receive_msg (receive.c:264)\r\n==56832==    by 0x49BDFC: receive_tcp_msg (tcp_read.c:1230)\r\n==56832==    by 0x49E0EB: tcp_read_req (tcp_read.c:1445)\r\n==56832==    by 0x4A0CB6: handle_io (tcp_read.c:1619)\r\n==56832==    by 0x493237: io_wait_loop_epoll (io_wait.h:1065)\r\n==56832==    by 0x4A2B05: tcp_receive_loop (tcp_read.c:1789)\r\n==56832==    by 0x509C52: tcp_init_children (tcp_main.c:4796)\r\n==56832==    by 0x423465: main_loop (main.c:1708)\r\n==56832==  Address 0x56d8fd0 is 640,384 bytes inside a fragment data (init) of size 8,119,728 client-defined\r\n==56832==    at 0x64E1EB: qm_malloc_init (q_malloc.c:261)\r\n==56832==    by 0x6584E7: qm_malloc_init_pkg_manager (q_malloc.c:1117)\r\n==56832==    by 0x642A23: pkg_init_manager (pkg.c:68)\r\n==56832==    by 0x4244FD: main (main.c:1931)\r\n```\r\n\r\nThe custom naming of the blocks (\"fragment data\") and the offset reported do not work as I expect: I'd expect the fist error to happen in a block named \"fragment header\" at its end and the last one in \"fragment data\" at its end too, so either my expectations are wrong or my code is.\r\n\r\nAlso I did not cover the instrumentation of the memory join code yet, so this should only be correct when **mem_join=0**."}],"action":{"name":"View Issue","url":"https://github.com/kamailio/kamailio/issues/949#issuecomment-283141244"}}}</script>