[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about top
- To: Miki Shapiro <aris(at-nospam)pharoe.com>
- Subject: Re: Question about top
- From: Shaul Karl <shaulka(at-nospam)bezeqint.net>
- Date: Thu, 02 Aug 2001 19:45:07 +0300
- cc: Happy Linux Campers <linux-il(at-nospam)linux.org.il>
- Delivered-To: linux.org.il-linux-il@linux.org.il
- In-Reply-To: Message from Miki Shapiro <aris@pharoe.com> of "Thu, 02 Aug 2001 10:31:51 +0300." <Pine.LNX.4.21.0108021026121.7156-100000@pharoe.com>
- References: <Pine.LNX.4.21.0108021026121.7156-100000@pharoe.com>
- Sender: linux-il-bounce(at-nospam)cs.huji.ac.il
>
> 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..
>
What is your compilation command line? In particular, do you ask to see
warnings when compiling on Linux? on Win32?
Have you tried using the memory debugging tools?
With C you have -lefence and others. Don't know if they work with other
languages but I guess the basic ones do.
Do report us if you'll track down this one.
> 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
>
--
Shaul Karl <shaulka@bezeqint.net>
=================================================================
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