[OpenSIPS-Users] OpenSIPS 1.4.2 memory corruption issue under extreme load?

[Bogdan-Andrei Iancu]

Hi Sergio,

First, some helper facts:

1) the message buffer is kept in private memory, so it cannot be written 
by other processes

2) parsing of the first via is done before starting the script 
execution, so, none of the modules can interfere with the buffer.

So, how do you get the TRACE log ? do you use the SIP TRACE module?

Is the TRACE log after the via error?

Regards,
Bogdan

Serge JF wrote:
> Hello, 
>
> We run a very high volume OpenSIPS 1.4.2 deployment with over 6 million
> calls processed daily on a single server running CentOS 5. After 3 days at
> maximum load we started seeing errors such as:
>
> Feb 28 08:03:17 sip101 /usr/local/sbin/opensips[11614]:
> ERROR:core:parse_via:  invalid port number
> <5060?branch=z9hG4bK49a93615-0234-0065adf8-8162901a-4330cddf> 
>
> You'll notice the question mark ? after the port number. The OpenSIPS parser
> does not like this and fails in the parsing - which had to be expected. The
> issue is that the message according to the XLOG statement we got at the very
> beginning of our route[] was received with a semicolon as expected:
>
> Feb 28 08:03:17 sip101 /usr/local/sbin/opensips[11614]: TRACE:ROUTE:
> time(1235826197) src(63.xx.xx.108:5060) dst(8.xx.xx.14:5060) msg(INVITE
> sip:+18566654221 at 4.xx.xx.227:5060 SIP/2.0
>  From: <sip:+18668496441 at 63.xxx.xx.108:5060>;tag=telstage-67aa-49a935d9
>  To: sip:+18566654221 at 8.xx.xx.19;tag=gK02b2b6e2
>  Contact: <sip:63.xxx.xx.108:5060;transport=udp>
>  Call-ID: 49a935d9-029f-0065abfa-8162901a-4330cddf at 63.xxx.xx.108
>  CSeq: 32043 INVITE
>  Content-Length: 177
>  Content-Type: application/sdp
>  Content-Disposition: session; handling=required
>  Route: <sip:8.xx.xx.14:5060;lr;ftag=telstage%2D67aa%2D49a935d9>
>  Session-Expires: 1800;refresher=uac
>  Supported: timer
>  Max-Forwards: 70
>  Via: SIP/2.0/UDP
> 63.xxx.xx.108:5060;branch=z9hG4bK49a93615-0234-0065adf8-8162901a-4330cddf
>
> Could this be due to some overwriting of string buffers in the OpenSIPS CORE
> or TM module? How should we go about debugging this issue? It only seems to
> happen after a few days under load. For the time being we have introduced a
> nightly restart of the OpenSIPS to clear up the memory.
>
> Any pointer (sic) would be most welcome!
>
> Best Regards,
>
> Serge
>