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.
Executing this code (new function in the **malloc_test** module):
```C
static int mt_pkg_overflow_f(struct sip_msg* msg, char *p1,char *p2) {
        int i;
        unsigned long *a;

        a = pkg_malloc(1024 * sizeof(unsigned long));

        if (!a) {
                LM_ERR("no more pkg\n");
                return -1;
        }

        *(a - 1) = 0xdeadbeef;
        *(a + 1024) = 0xdeadc0de;
        for (i = 0 ; i < 1024; i++) {
                a[i] = (long)i;
        }

        return 1;
}
```
immediately triggers these errors:
```
==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)
```

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.

Also I did not cover the instrumentation of the memory join code yet, so this 
should only be correct when **mem_join=0**.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/949#issuecomment-283141244
_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Reply via email to