On Sun, Nov 12, 2006 at 09:55:52AM -0800, John L Fjellstad wrote: > Paul E Condon <[EMAIL PROTECTED]> 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. Thanks -- Paul E Condon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
