[Serusers] receive_msg: no mem for sip_msg

Bogdan-Andrei IANCU iancu at fokus.fraunhofer.de
Wed Nov 10 16:36:02 CET 2004


Hi Gwen,

it will be safer to uninstall first the 0.8.12 version.
out of curiosity, since the problem you reported is quite strange, have 
you tried db_mod 2?

bogdan

g.billoudet at arwen-tech.fr wrote:

>Hi,
>
>If I don't use "serctl alias add", I still get the same error message...
>I will try to upgrade ser:
>- Should I uninstall ser 0.8.12 and then install 0.8.14
>- Or should I install 0.8.14 directly ?
>
>Thanks
>
>  Gwen
>
>
>  
>
>>Try to install 0.8.14.
>>
>>  Jan.
>>
>>On 10-11 14:27, Bogdan-Andrei IANCU wrote:
>>    
>>
>>>Hi Gwen,
>>>
>>>try to set back db_mode to 1 or 2 but without adding the aliases via
>>>serctl. I'm trying to figure out if it's a problem in DB part or in fifo
>>>part of usrloc.
>>>
>>>bogdan
>>>
>>>g.billoudet at arwen-tech.fr wrote:
>>>      
>>>
>>>>Hi, thanks for help
>>>>
>>>>I used serctl alias add 1234 sip:gwenael at arwen-tech.fr just after
>>>>        
>>>>
>>>starting
>>>      
>>>
>>>>ser :
>>>>- When I set modparam("usrloc", "db_mode", 0), ser works fine and I can
>>>>have phone calls but I can't use this alias of course...
>>>>- When I ser modparam("usrloc", "db_mode", 1), ser just doesn't work at
>>>>all.
>>>>
>>>>My aliases table is empty when I start ser. I am using ser 0.8.12.
>>>>
>>>> Gwen
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>On 10-11 11:41, Bogdan-Andrei IANCU wrote:
>>>>>
>>>>>          
>>>>>
>>>>>>Jan Janak wrote:
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>On 10-11 10:01, Bogdan-Andrei IANCU wrote:
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>my first guess is that use at start-up time you have an intensive
>>>>>>>>private memory consumer which gets into conflict with the SIP
>>>>>>>>                
>>>>>>>>
>>>messages
>>>      
>>>
>>>>>>>>receiver.
>>>>>>>>
>>>>>>>>Judging after the error (in receive loop) I'm sure you have some
>>>>>>>>                
>>>>>>>>
>>>SIP
>>>      
>>>
>>>>>>>>traffic at start-up  - please check with tcpdump or ngrep - it can
>>>>>>>>                
>>>>>>>>
>>>be
>>>      
>>>
>>>>>>a
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>>REGISTER, SUBSCRIBE, etc
>>>>>>>>
>>>>>>>>Looking into your script, I would say only usrloc can be the
>>>>>>>>                
>>>>>>>>
>>>intensive
>>>      
>>>
>>>>>>>>private memory consumer - if you have a lot of entries in DB
>>>>>>>>                
>>>>>>>>
>>>(usrloc
>>>      
>>>
>>>>>>and
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>>aliases). To check this theory, try to start ser with DB disabled
>>>>>>>>                
>>>>>>>>
>>>in
>>>      
>>>
>>>>>>>>usrloc; set:
>>>>>>>>	modparam("usrloc", "db_mode", 0)
>>>>>>>>
>>>>>>>>please see if you still get the error and also please confirm if
>>>>>>>>                
>>>>>>>>
>>>you
>>>      
>>>
>>>>>>>>have or not sip traffic.
>>>>>>>>                
>>>>>>>>
>>>>>>>I don't think this is the problem. usrloc consumes private memory
>>>>>>>before SER forks (and at that stage it does not process SIP
>>>>>>>              
>>>>>>>
>>>>>>messages),
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>when re-loading data from the database. It would fail to start if
>>>>>>>              
>>>>>>>
>>>>>>this
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>was the problem, so I think there must be some other memory problem.
>>>>>>>              
>>>>>>>
>>>>>>I was considering the possibility of memory fragmentation. If there
>>>>>>            
>>>>>>
>>>are
>>>      
>>>
>>>>>>a lot of usrloc/aliases records to be loaded, memory can get to
>>>>>>fragmented to be able later to alloced a bigger size chunk.
>>>>>>            
>>>>>>
>>>>>Bot tables (aliases, location) are empty:
>>>>>
>>>>> 0(0) preload_udomain(): Table is empty
>>>>> 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply
>>>>> 0(0) fixing /usr/local/lib/ser/modules/registrar.so lookup
>>>>> 0(0) preload_udomain(): Table is empty
>>>>>
>>>>>   Jan.
>>>>>
>>>>>          
>>>>>
>>>>        
>>>>
>
>
>  
>




More information about the sr-users mailing list