I have added valgrind instrumentation directives to q_malloc, but I suspect memcheck doesn't know how to check shared memory accessed be several processes.

for pkg memory, it gives correct reports such as:

==134243== 13,584 bytes in 104 blocks are definitely lost in loss record 438 of 451
==134243==    at 0x64E0D0: qm_detach_free (q_malloc.c:270)
==134243==    by 0x64EBC7: qm_malloc (q_malloc.c:415)
==134243==    by 0x70A26C: addstr (cfg.lex:1382)
==134243==    by 0x70A1DB: addchar (cfg.lex:1366)
==134243==    by 0x70653D: yylex (cfg.lex:1170)
==134243==    by 0x71305D: yyparse (cfg.tab.c:4775)
==134243==    by 0x425A8C: main (main.c:2137)

(this "leak" is expected though)

but for any operation in shm, it gives (only, and tons of) inconsistent reports such as:

==134284== Invalid read of size 4
==134284==    at 0x4C94D2: atomic_get_and_set_int (atomic_x86.h:223)
==134284==    by 0x4C9677: futex_release (futexlock.h:134)
==134284==    by 0x4EEAFB: tcpconn_do_send (tcp_main.c:2548)
==134284==    by 0x4EBEC9: tcpconn_send_put (tcp_main.c:2289)
==134284==    by 0x4E9733: tcp_send (tcp_main.c:2046)
==134284==    by 0x6E2F612: msg_send_buffer (forward.h:218)
==134284==    by 0x6E3204F: send_pr_buffer (t_funcs.c:70)
==134284==    by 0x6DD4A5F: _reply_light (t_reply.c:554)
==134284==    by 0x6DD56C6: _reply (t_reply.c:659)
==134284==    by 0x6DDC7D5: t_reply (t_reply.c:1552)
==134284==    by 0x6DF1E02: w_t_reply (tm.c:1246)
==134284==    by 0x6DF7EE4: w_t_reply_wrp (tm.c:2041)
==134284==  Address 0x9691ce0 is not stack'd, malloc'd or (recently) free'd

I've pushed the work in this branch: https://github.com/kamailio/kamailio/tree/tmp/valgrind

Do you have any info on whether memcheck can deal with shared pools?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.