[OpenSIPS-Users] segmentation fault when calling pkg_malloc

[Bogdan-Andrei Iancu]

Hi Chevio, Hi Kolev,

That is true what Kolev says - most probably you have a memory overwrite 
somewhere and you are messing up the data structure of the memory 
manager. It cannot be a race as the pkg memory is per process, so it is 
not shared.

To try to catch the bug, enable memory debugger - it will try to detect 
and report mem overflow, double free, etc...See:
http://www.opensips.org/pmwiki.php?n=Resources.DocsTsMem
"how to handle it" chapter

Regards,
Bogdan

Vasil Kolev wrote:
> В 14:10 -0700 на 11.03.2009 (ср), Chevio написа:
>   
>> Hi, All,
>>
>> I am getting a segmentation fault when calling pkg_malloc from a custom
>> module in opensips 1.4.4 notls,
>>
>> here is the offending code :
>>
>> int tncgw_ip_lookup(struct sip_msg* msg, char* _para1, char* _para2)
>> {
>>
>> 	str  _user_ip;
>> 	db_res_t* db_res = NULL;
>> 	char* strsql=NULL;
>> 	char* to_prefix=NULL;
>> 	char* new_uri=NULL;
>> 	char* new_to=NULL;
>> 	str strsqlstr;
>> 	str techprefix;
>> 	str to;
>> 	int retval=-1;
>> 	int dbg=1;
>>
>> 	if(dbg)LM_INFO("TNCGW ip_address_lookup 2009.03.11.a beta\n");
>>
>> 	techprefix.s=NULL;
>> 	_user_ip.s=NULL;
>>
>> 	if(dbg) LM_INFO("---Memory allocation\n");
>>
>> 	strsql=pkg_malloc(100);
>> 	new_to=pkg_malloc(MAX_URI_SIZE); ## this is the line 97
>> 	new_uri=pkg_malloc(MAX_URI_SIZE);
>> 	to_prefix=pkg_malloc(8);
>>
>>
>> and here is the  back trace
>>
>> Program terminated with signal 11, Segmentation fault.
>> [New process 32735]
>> #0  fm_malloc (qm=0x8183b00, size=<value optimized out>) at
>> mem/f_malloc.c:125
>> 125                             if (frag->size <= (*f)->size) break;
>> (gdb) bt
>> #0  fm_malloc (qm=0x8183b00, size=<value optimized out>) at
>> mem/f_malloc.c:125
>> #1  0xb7ab0873 in tncgw_ip_lookup (msg=0x8196ed8, _para1=0x0, _para2=0x0) at
>> tncgw.c:97
>> #2  0x08055275 in do_action (a=0x818d278, msg=0x8196ed8) at action.c:845
>> #3  0x08054172 in run_action_list (a=0x818d278, msg=0x8196ed8) at
>> action.c:138
>> #4  0x080a0516 in eval_expr (e=0x818d2e0, msg=0x8196ed8, val=0xbf8d4ef8) at
>> route.c:1133
>> #5  0x08053e2f in do_assign (msg=0x8196ed8, a=0x818d308) at action.c:207
>> #6  0x080549f5 in do_action (a=0x818d308, msg=0x8196ed8) at action.c:951
>> #7  0x08054172 in run_action_list (a=0x818d308, msg=0x8196ed8) at
>> action.c:138
>> #8  0x08056845 in do_action (a=0x818d8c0, msg=0x8196ed8) at action.c:717
>> #9  0x08054172 in run_action_list (a=0x8189fd0, msg=0x8196ed8) at
>> action.c:138
>> #10 0x080577f4 in run_top_route (a=0x8189fd0, msg=0x8196ed8) at action.c:118
>>
>> does it mean I ran out of memory? if that is the case pkg_malloc should
>> return a 0 instead of crashing.
>>     
>
>
> This doesn't seem like running out of memory, more like a memory
> corruption. The first thing to check is if either 'frag' or 'f' are NULL
> or invalid (e.g. in gdb do "print f", "print frag" and see what does
> that say). After that try dereferencing them, seeing how could they get
> these values, etc.
>
> If this isn't reproducible every time, it might also mean a race
> condition, that something else is fucking up the situation, in which
> case _probably_ valgrind can help (although I never had a lot of luck
> using it on opensips).
>
>