[OpenSIPS-Users] segmentation fault when calling pkg_malloc

[Dan Pascu]

On Sunday 15 March 2009, Vasil Kolev wrote:
> В 05:43 +0200 на 15.03.2009 (нд), Dan Pascu написа:
> > On Thursday 12 March 2009, Vasil Kolev wrote:
> > > This doesn't seem like running out of memory, more like a memory
> > > corruption. The first thing to check is if either 'frag' or 'f' are
> > > NULL or invalid (e.g. in gdb do "print f", "print frag" and see
> > > what does that say). After that try dereferencing them, seeing how
> > > could they get these values, etc.
> >
> > I've seen this thing before. I'm willing to bet that the pointers are
> > not NULL. They are most likely composed of ascii byte codes from some
> > SIP message header (as a result of the allocator memory being
> > overwritten by part of the processed message).
> >
> > Unfortunately I have no idea what causes this, and the only solution
> > to a similar problem I was experiencing was to replace the opensips
> > private memory allocator with the system memory allocator when
> > building opensips.
> >
> > Maybe the thread author can try using the system memory allocator to
> > see if the problem goes away. If so, we definitely have a problem
> > with the memory allocator. If not, he may have a different issue
> > somewhere else in his code.
>
> "Oh shit" seems like the appropriate response :)
> (I'm not the thread author, but this would seem to affect me too)
>
> Anyway, there seem to be three different memory allocators in opensips
> - vqm_malloc, fm_malloc and qm_malloc (this is from looking in
> mem/mem.h), is it possible that one has an issue and the rest not? Now
> the issue might be that the system memory allocator is more resilient
> to some strange type of corruption (for example, single byte overflow
> of strings) and doesn't have this weird issue...

The private memory pool used by the internal memory allocator is a 1 MB 
area right after the area where static variables are stored. It may be 
possible that there is a buffer overflow when writing to some static 
variables that gets to write in this pool overwriting the allocator 
internal structure. The system memory doesn't have this problem as it is 
stored somewhere else. Such a buffer overflow will even go unnoticed by 
memory tracing tools as it sees that the write is done in the 1MB that 
the program allocated, having no clue that the area is actually managed 
by another memory allocator that can get corrupted.

At the same time I do not imply that this is what happens. The way the 
memory is corrupted doesn't suggest this pattern as the private memory is 
not overwritten from the beginning. It looks more like specific areas are 
overwritten as if the memory allocator thinks that the memory area was 
released and gives it to someone else on the next call to pkg_malloc, 
resulting in 2 different pointers to the area competing for the memory.

-- 
Dan