[OpenSIPS-Users] Critical:core:anchor_lump: offset exceeds message size (1033 > 1000), abort
Bobby Smith
bobby.smith at gmail.com
Thu Apr 16 23:26:54 CEST 2009
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
<bogdan at voice-system.ro>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 <bogdan at voice-system.ro <mailto:
>> bogdan at voice-system.ro>>
>>
>> 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
>>
>> bobby.smith at gmail.com <mailto:bobby.smith at gmail.com> 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
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090416/c2c6c636/attachment-0001.htm
More information about the Users
mailing list