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):

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, view it on GitHub, or mute the thread.