[OpenSIPS-Users] Critical:core:anchor_lump: offset exceeds message size (1033 > 1000), abort

[Bogdan-Andrei Iancu]

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
>          
>
>
>