[sr-dev] [kamailio/kamailio] support valgrind when *_MALLOC is used (#949)

[Camille Oudot]

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 or view it on GitHub:
https://github.com/kamailio/kamailio/issues/949#issuecomment-282311321
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20170224/2df93574/attachment-0001.html>