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

Re: Question about top



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

Can anyone explain the big buffer deallocation problem? theories?

Thx.

---= Miki Shapiro =------------------
 ---= Cell: (+972)-56-322433 =--------
  ---= ICQ: 3EE853 =-------------------
   ---= Windows Programmer in Rehab =---
    -------------------------------------

"If at first you don't succeed...
.. Skydiving is probbably not for you."

On Thu, 2 Aug 2001, Ira Abramov wrote:

> On Thu, 2 Aug 2001, Miki Shapiro wrote:
> 
> > Yes, I have a huge array of pointers to class objects, each containing a
> > name and attribute map of the archive contents.
> 
> well, the question if it's got any leakes, and if your data structure is
> efficiant. when using such huge arrays, the little optimizxations are
> critical
> 
> > I actively use this map, and I'm fairly sure it gets might full.
> > I still don't see why ~4000 filenames (strings alloced with MAX_PATH
> > bytes) and their corresponding attribute bits eat up a gig and a half, and
> > where the non-SGI-redhat-running-on-i386 allocates this ram from. or does
> > it? Just how reliable is top anyway? better progs? ideas?
> 
> top shows what the kernel gives it from /proc. and like Yaron said, Lazy
> allocation means you get an "ok" from the kernel on pages you ask for,
> but they are only ever allocated for REAL if you actually use them. At
> that time your process, or kernel will crash (depends on the situation)
> when you actually use it.
> 
> one reason that comes to my mind: you keep extending the array by
> copying it rather than linking a new array or something of the sort, and
> forget to clean up after you. you haven't mentioned if you are using
> something like a Java VM where you can tweak the garbage collection
> parameters or C++ code.
> 
> > > > Anything about how my code allocs/deallocs that screws top completely
> > > > up? Ideas?
> 
> that is up to you to figure out with a debugger maybe, we can't tell
> from here, but ofcourse it could be the case.
> 
> > > > Linux november 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown
> 
> time to update anyway. 2.2.19 latest IIRC. check the changelog to see if
> such a problem was reported.
> 
> 
> -- 
> (@-    GNU/Linux -
> //\       Best thing since the invention of the cat
> v_/_
> 
> 
> =================================================================
> 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
> 


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