[OpenSIPS-Devel] need help to troubleshot issues

[Bogdan-Andrei Iancu]

Hi Di-Shi,

My guess is (as your module probably does external communication via 
network) that some function in your module does block in a I/O op while 
trying to communication with an external entity.

Based on your description I do not see how opensips it self can block 
(like the sl_send_reply() function).

So, to debug something like that, simply "block" all opensips processes 
and then attach to them with gdb in order to take a backtrace (while 
opensips still running) - this will indicate where the processes blocked.

Attach to the SIP worker processes - they are blocking ; the fifo 
process works ok as it does not handle SIP traffic, so it does no block .

Regards,
Bogdan

On 02/06/2012 05:48 AM, Di-Shi Sun wrote:
> Hi All,
> We are testing our module that gets routing info from outside of 
> OpenSIPS. OpenSIPS routes calls based on these info. If our module 
> returns empty routing info for a call to OpenSIPS, OpenSIPS uses 
> sl_send_reply to fail the call.
> In heavy load, our module returns empty routing info to OpenSIPS 
> quickly. Soon, all OpenSIPS SIP listen threads stick forever. OpenSIPS 
> does not crash and it can still accept fifo command. We did not see 
> any error message in OpenSIPS log. We also did not see any memory 
> related message. If we make our module to return the empty routing 
> info slower, OpenSIPS SIP listen threads do not stick.
> Would you please tell me what issue it may be and which part I should 
> dig more deep?
> Thanks,
> Di-Shi Sun
> VoIP Routing, Accounting, Security
> www.TransNexus.com <http://www.TransNexus.com>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20120212/930cc6c9/attachment.htm>