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

Daniel-Constantin Mierla miconda at gmail.com
Fri Mar 26 19:40:21 CET 2010


Hello,

On 3/26/10 4:13 PM, Zappasodi Daniele wrote:
>
> Hello,
>
> this is what I get with gdb:
>
> (gdb) bt full
>
> #0 0x40137e54 in sched_yield () from /usr/local/lib2/libc.so.6
>
> No symbol table info available.
>
> I don't think that it can help, but I am not able to load the symbol 
> table for openser on the server.
>
hmm, strange. Did you try with many processes? Sam result in the backtrace?

Cheers,
Daniel

> 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. 
> **********************************************************************
>

-- 
Daniel-Constantin Mierla * http://www.asipto.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20100326/eb1c905d/attachment.htm>


More information about the sr-dev mailing list