Hi Bobby,

Thanks for your help with tracing and debugging this problem. It should 
be fixed now - the fix is available on all branches + trunk on SVN.
I ran several tests and it looks good - the problem was with malformed 
messages were the Content-len hdr was advertising a length longer the 
real package size, leading to overflow - now, such cases are detected 
and an err is reported instead of simply crashing :).

Please update and test.

Thanks again,
Bogdan

Bobby Smith wrote:
> Opensips 1.4.5 -- the latest release as of yesterday (non-1.5).
>
> Working on getting you your trace now, will take a few minutes.
>
> Much thanks.
>
> 2009/3/24 Bogdan-Andrei Iancu <[email protected] 
> <mailto:[email protected]>>
>
>     Hi Bobby,
>
>     can you get the logs with debug=6 and post (or send priv to me) ?
>     Also, what is the rev number your are using?
>
>
>     Regards,
>     Bogdan
>
>     [email protected] <mailto:[email protected]> wrote:
>
>         A little more information into the problem. We enabled some
>         additional logging around the point where the anchor_lump
>         function was being called to print out the contents of the SIP
>         message. You can see that after processing this message
>         several times, it craps out and kills all the children processes.
>
>         If someone could once over the routing script that I included
>         to see, if for example, that I'm trying to correct a nat'ed
>         contact where I shouldn't be, that would be much appreciated.
>         Further, if that's not the case, is there a way where we can
>         gracefully kill one child without killing the whole application?
>
>         Last -- this is with an emergency update to production to
>         Opensips 1.4.5 last night. This happened this morning around
>         9. More importantly, Opensips consumed temporarily almost 2 GB
>         of memory before dying, and then cached it. Huge memory spike.
>
>         Again, tunables: 32 MB private per process, 16 processes total
>         (at this point, we figured less private memory, more processes
>         to work the CPU), 512 Shared memory, on a 4 GB, 2 x Dual Core box.
>
>
>
>         
> ------------------------------------------------------------------------
>
>         _______________________________________________
>         Users mailing list
>         [email protected] <mailto:[email protected]>
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>          
>
>
>


_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to