[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about top
- To: Happy Linux Campers <linux-il(at-nospam)linux.org.il>
- Subject: Re: Question about top
- From: Miki Shapiro <aris(at-nospam)pharoe.com>
- Date: Thu, 2 Aug 2001 10:31:51 +0300 (IDT)
- Delivered-To: linux.org.il-linux-il@linux.org.il
- In-Reply-To: <Pine.LNX.4.33_heb2.09.0108020855460.827-100000@green>
- Sender: linux-il-bounce(at-nospam)cs.huji.ac.il
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