This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: ctor_copy_dtor.cc still consuming outrageous amounts of memory
On Sun, Jan 28, 2001 at 02:29:52PM +0000, Nix wrote:
> > There is logic in mkcheck.in to limit the amount of memory used by
> > each test, and it was working for a time. (In fact it worked too well;
> > we had to increase the limit to 3MB to get some of the tests to pass.)
>
> Ooops. I'd say something like 16Mb is more sensible; I guess it really
> depends on the size and load of the system you're running the tests on.
> (Time for a configure option?)
A config option sounds like overkill; the limit is easily tweakable
(search for the regexp ^MAX_MEM_USAGE in mkcheck[.in]).
> > Which platform are you using?
>
> i586-pc-linux-gnu, 128Mb physical RAM, 520Mb swap of which about 400Mb
> was free when ctor_copy_ctor killed things.
512MB here, with about a gig of swap... it all gets used.
The SPARC I was using to test has 1.5GB physical and, I can't recall now,
"lots" of swap. Watching the test thrash that machine to the ground
was painful.
> I've got it working now. Basically, using `ulimit -d' to limit new'ed
> space works only on platforms with a malloc/new implementation that
> works by messing with brk() and friends; modern mallocs, like the one in
> glibc2 (and therefore most modern news as well) allocate big lumps of
> memory by mmap()ing them, and that has to be restricted with `ulimit -v'
> instead.
Ah, we must be careful here. There are plenty of modern mallocs that still
use brk, if the OS works better with brk. The latest version of Solaris,
for example, uses a brk'ing malloc by default.[*] So the limit was still
taking effect on that platform.
What to do, what to do... I'll add a call to 'ulimit -v' and see what
the memory limit needs to be set to, for starters.
What will happen under DejaGNU, I wonder?
Phil
[*] Does anyone else think that "The Brking Mallocs" would be a really
great name for a rock band? Okay, it's just me.
--
pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools. Fools are protected by more capable fools.