[SR-Users] valgrind errors from 3.1-stable (git 2fe4d633e4ac)

marius zbihlei marius.zbihlei at 1and1.ro
Fri Apr 1 09:29:51 CEST 2011


On 03/31/2011 07:52 PM, Timo Teräs wrote:
> Hi all,
>
> I'm running 3.1-branch git head currently under valgrind. And I've seen
> several invalid reads and writes (apparently most are off by one).
>    

Hello,

I haven't used Valgrind memcheck tool for Kamailio , but from what I 
know it might not be that useful. What Valgrind does it hooks into the 
memory allocation functions like malloc/calloc/realloc/alloca and keeps 
track of said allocation. Because, by default, Kamailio uses it's own 
memory manager (both for private memory or shared), this messes up on 
how Valgrind can keep track of its allocation/deallocation.

I don't know if there is a way to make Valgrind to work reliable with K 
memory managers, but I will take a look on the cases you provide just to 
be sure.

As a side note, I had uses static analysis tools quite succesfully on 
3.1 . I had use clang analyzer from the llvm suite. There are still some 
outstanding bugs which I didn't had time to look at.

Marius
> ==22274== Invalid read of size 1
> ==22274==    at 0x6DA2C0A: pv_set_ruri_user (pv_core.c:1755)
> ==22274==    by 0x13BA15: lval_pvar_assign (lvalue.c:357)
> ==22274==    by 0x13BF0F: lval_assign (lvalue.c:405)
> ==22274==    by 0x139E4D: do_action (action.c:1472)
> ==22274==    by 0x13A6F1: run_actions (action.c:1555)
> ==22274==    by 0x12FDEB: do_action (action.c:711)
> ==22274==    by 0x13A6F1: run_actions (action.c:1555)
> ==22274==    by 0x13A86F: run_actions_safe (action.c:1607)
> ==22274==    by 0x1E2666: rval_get_int (rvalue.c:904)
> ==22274==    by 0x1E5252: rval_expr_eval_int (rvalue.c:1866)
> ==22274==    by 0x131B8A: do_action (action.c:1071)
> ==22274==    by 0x13A6F1: run_actions (action.c:1555)
>
> Is fairly obvious. modules_k/pv/pv_core.c has several places which take
> backup of "val->rs.s[val->rs.len]" and replaces it with zero for string
> termination. It's than later on set back to the original value. However,
> it would appear that the value passed does not always point to a memory
> area which is large enough. This results in multiple invalid reads and
> writes of one.
>
> The remaining reads are not so clear to me.
>
> ==22274== Invalid read of size 1
> ==22274==    at 0x4811A69: strncpy (mc_replace_strmem.c:339)
> ==22274==    by 0x6DA77FF: set_var_value (pv_svar.c:122)
> ==22274==    by 0x6DA1EDB: pv_set_scriptvar (pv_core.c:1636)
> ==22274==    by 0x13BA15: lval_pvar_assign (lvalue.c:357)
> ==22274==    by 0x13BF0F: lval_assign (lvalue.c:405)
> ==22274==    by 0x139E4D: do_action (action.c:1472)
> ==22274==    by 0x13A6F1: run_actions (action.c:1555)
> ==22274==    by 0x131E05: do_action (action.c:1086)
> ==22274==    by 0x13A6F1: run_actions (action.c:1555)
> ==22274==    by 0x12FDEB: do_action (action.c:711)
> ==22274==    by 0x13A6F1: run_actions (action.c:1555)
> ==22274==    by 0x131E05: do_action (action.c:1086)
>
> ==22274== Invalid read of size 2
> ==22274==    at 0x4811E1F: memcpy (mc_replace_strmem.c:523)
> ==22274==    by 0x1E134D: rval_new_str (rvalue.c:269)
> ==22274==    by 0x1E394E: rval_convert (rvalue.c:1301)
> ==22274==    by 0x1E4780: rval_str_add2 (rvalue.c:1610)
> ==22274==    by 0x1E8681: rval_expr_eval (rvalue.c:2399)
> ==22274==    by 0x13BBD9: lval_assign (lvalue.c:389)
> ==22274==    by 0x139E4D: do_action (action.c:1472)
> ==22274==    by 0x13A6F1: run_actions (action.c:1555)
> ==22274==    by 0x12FDEB: do_action (action.c:711)
> ==22274==    by 0x13A6F1: run_actions (action.c:1555)
> ==22274==    by 0x139229: do_action (action.c:1342)
> ==22274==    by 0x13A6F1: run_actions (action.c:1555)
>
> Any ideas how to fix these? Or any instructions what to provide more in
> the bug report?
>
> Cheers,
>   Timo
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>    




More information about the sr-users mailing list