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

Re: C++ exception handling question [solved]

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. 

Paul E Condon           

Reply to: