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

Re: Question about top



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