[sr-dev] [Kamailio-Users] Fast lock loop with arm

Zappasodi Daniele Daniele.Zappasodi at seltatel.it
Wed Mar 24 16:54:43 CET 2010


I use openser 1.3.4.
Next time that the loop happens I'll try to keep the backtrace.
 
thanks,
Daniele
 

-----Messaggio originale-----
Da: Daniel-Constantin Mierla [mailto:miconda at gmail.com]
Inviato: mercoledì 24 marzo 2010 16.47
A: Zappasodi Daniele
Cc: users at lists.kamailio.org; sr-dev
Oggetto: Re: [Kamailio-Users] Fast lock loop with arm


Hello,

what version of kamailio do you use?

Can you grab a backtrace with gdb once you get this high cpu usage? Spot one of the processes, take the pid and do:

gdb  /path/to/kamailio  _pid_

Then:

bt

You should see the bactrace of executed function getting to deadloc. Make sure you get at least one SIP worker process backtrace (do kamctl ps to see the type of kamailio process).

Cheers,
Daniel

On 3/24/10 4:29 PM, Zappasodi Daniele wrote: 

Hi, 
I have a big problem with fast lock mutex on arm CPU: 
sometimes I find one or more children that go in an infinite loop, in the while loop of get_lock function. 
They remain in Run for long time (sometimes hours) and openser keeps 100% CPU. 

Now I have changed the functions get_lock and tsl in order to obtain more info and 
I observe that  (if and) when the process finish the cycle, it have done a big amount of cycles.  

This the log with my added info: 
Mar 26 20:29:08 SAM-IP openser[1645]: NOTICE:tm:_lock: ret 1 (cycle) 
Mar 26 20:29:51 SAM-IP openser[1645]: NOTICE:tm:_lock: ret 1 (cycle) 
Mar 26 20:29:55 SAM-IP openser[1645]: NOTICE:tm:_lock: ret 1 (cycle) 

Mar 26 20:29:55 SAM-IP openser[1645]: NOTICE:tm:t_retransmit_reply: MYTM lock 
[process in loop] 
Mar 26 20:33:46 SAM-IP openser[1645]: NOTICE:tm:_lock: ret 59374917 (cycle) 
[after 4 minutes and 59374917 cycles, this is an example with a "short" loop] 
Mar 26 20:33:46 SAM-IP openser[1645]: NOTICE:tm:t_retransmit_reply: MYTM lock done 

I'm not able to recognize the call flow that generates the loop (I know only that it always happens when t_retransmit_reply calls LOCK_REPLIES), 

but I urgently need a work around to escape from the loop. 

This is the get_lock function with my counter j: 

inline static int get_lock(fl_lock_t* lock) 
{ 
#ifdef ADAPTIVE_WAIT 
        int i=ADAPTIVE_WAIT_LOOPS; 
        int j=1;                                        /***** my change ****/ 
#endif 
        
        while(tsl(lock)){ 
#ifdef BUSY_WAIT 
#elif defined ADAPTIVE_WAIT 
                j++;                            /***** my change ****/ 
                if (i>0) i--; 
                else sched_yield(); 
#else 
                sched_yield(); 
#endif 
        } 
        return(j); 
} 

Can I break the lock when my counter reaches a big value? 
Should I call the unlock function after the break? 
which value can be considered too big? 

Thanks, 
Daniele 



********************************************************************** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. **********************************************************************



_______________________________________________

Kamailio (OpenSER) - Users mailing list

Users at lists.kamailio.org

http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

http://lists.openser-project.org/cgi-bin/mailman/listinfo/users


-- 
Daniel-Constantin Mierla * http://www.asipto.com/ 


**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this 
message
by anyone else is unauthorized. If you are not the intended 
recipient, any
disclosure, copying, or distribution of the message, or any action 
or
omission taken by you in reliance on it, is prohibited and may be 
unlawful.
Please immediately contact the sender if you have received this 
message in error.


**********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20100324/f23eade4/attachment-0001.htm>


More information about the sr-dev mailing list