Re: C++ exception handling question [solved]
On Mon, Nov 13, 2006 at 12:22:27AM -0500, hendrik@topoi.pooq.com wrote:
> On Sun, Nov 12, 2006 at 08:31:42PM -0700, Paul E Condon wrote:
> > On Sun, Nov 12, 2006 at 09:55:52AM -0800, John L Fjellstad wrote:
> > > Paul E Condon <pecondon@mesanetworks.net> writes:
> > >
> > > > Thanks for stack profiling info. I wonder if this _is_ a reportable
> > > > bug. After all, there is a lot of information on the 'bad_alloc'
> > > > exception in various sources. If GNU C++ library doesn't try to throw
> > > > this exception until it is too late for the throw to succeed, what
> > > > good is it? And, how was its operation verified during testing on a
> > > > Debain box? At the point where it kill happens, I think the program is
> > > > allocating space for the contents of large STL vector of vectors. It
> > > > doesn't seem to me that this should be done on the stack, but I
> > > > haven't thought deeply on the issue.
> >
> > All my speculation as to the quality of GNU C++ compiler is
> > inoperative. The problem is in the kernel, as pointed out by John F.:
> >
> > >
> > > One thing you might not be aware of is that Linux overcommit the
> > > memory. That is, even if there is no memory left, it might tell the
> > > program that it has enough, since it expect that by the time you use the
> > > memory, it will be available. It's controlled by
> > > /proc/sys/vm/overcommit_memory.
> > >
> > > Check the man page for malloc (look under BUGS), and do some search in
> > > your favorite search engine.
> > >
> >
> > This is really interesting. man malloc calls the default behavior
> > of the kernel a really bad bug, with which I agree. kernel-docs
> > sysctl/vm.txt justifies the default by claiming it is helpful to
> > programmers who 'malloc() huge amounts of memory "just-in-case" and
> > don't use much of it.' I had thought such programmers were rare in the
> > Linux world, as they are all happily writing garbage code for
> > BillG. But, oh well. Now I know how to make my code work under Linux.
>
> It is reasonable to reserve large blocks of address space, if you need
> unknown amounts of contiguous space -- and then populate it later. This
> happens, for example, with some memory allocation algorithms. FOr
> specific applications, such techniques may be more efficient or
> otherwise appropriate than using malloc. But I do believe that if such
> a feature is provided, it should *not* be called malloc, which has other
> important uses.
I'm not a professional programmer, so my standards of reasonableness
are not tempered by 'real world' experience. I use C++ to write
simulation code for my research in biodiversity. It seems to me, from
reading the doc.s, that realloc() should be used in the situation that
you describe. It is possible to keep track of all places in the code
that new objects are brought into use and check if space is available
within the previously allocate block, and then use realloc() to expand
the allocation if needed.
Personally, I wonder about the quality of a program design that
requires that objects that are initialized at different times be
stored is a single contiguous block of RAM. I think that pointers and
references have long been known as a way to free oneself of this
problem. But, I'm not a professional.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: