Just to confirm, we verified the fix.  Thanks very much for your help!

On Wed, Apr 1, 2009 at 1:45 PM, Bogdan-Andrei Iancu
<[email protected]>wrote:

> 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