[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about top



* Miki Shapiro <aris@pharoe.com> [010802 15:39]:
> And here's the even weirder part:
> 
> I traced the leak to a 1MB buffer I allocate using new.
> 
> when I do:
> 
> delete [] pBuffer
> 
> It stays registered as allocated memory.
> 
> The moment I lowered it to a 50K buffer, the problem spontaneously
> vanished. What gets deleted then, stays deleted, is registered as deleted,
> and top doesn't blow the scale.
> 
> anyone know any linux-specific limitations with big buffers allocated
> using new ?

I don't know exactly about new, but malloc from the glibc (at least my
2.2.3 one) says that large amounts of memory that it allocates are
allocated using mmap and thus are restored directly when freed. Though
it sounds like you have it reversed...

btw, the overalocation case is possible in Linux and not only SGI, at
least in 2.4.x it is. When the process asks for the memory (writes to
it), and there is no memory and no swap space to throw stuff in, the
kernel will go OOM (Out Of Memory) and will start killing programs to
free the memory.

The problem with that scheme is that prog1 can allocate all the memory
and use most of it, then prog2 that asks for very little memory needs
just a bit more to use from what it allocated and will die because it
triggered OOM.

> 
> I don't know how relevant this is, but I encountered another prob a few
> days back when doing delete [] pObject instead of delete pObject worked
> fine on Win32 but segfaulted on Linux. doesn't seem relevant but what the
> hell..

This can be attributed to library differences and VM differences. This
things are very implementation dependent. And it isn't relevant.


-- 
Baruch Even
http://baruch.ev-en.org/

=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il