Date: Mon, 7 May 2001 08:46:58 +0300 (WET) From: Andris Pavenis To: Dennis Yelle Cc: djgpp AT delorie DOT com Subject: Re: new doesn't throw an exception In-Reply-To: <3AF42098.31EBA7FF@jps.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sat, 5 May 2001, Dennis Yelle wrote: > pavenis AT lanet DOT lv wrote: > > > > It seems that new is throwing bad_alloc but it's not catched. Attempt > > to catch (std::exception &) also doesn't help. Getting exception after > > memory is exhausted is a rather tricky thing as throwing exception may > > require additional memory we don't have in this case. > > > > I'm getting the same problem with gcc-2.95.3. When I'm changing > > 'new long' to 'new long[100]' > > I'm getting exception catched. > > That is really strange. > When I allocate 21 or more longs at a time, I can catch > the exception, but when I allocate 20 or fewer each time, > I get the stack dump. > That makes me think that the new in new1.cc is NOT the > one that is actually being called. Also, the > line number that symify shows does not match the new1.cc > that I have. > > I have these files: > gcc2953b.zip > gpp2953b.zip > gcc2953s.zip > > Is there supposed to be a > gpp2953s.zip ? > It seems that throwing bad_alloc exception tries to allocate memory with gcc-2.95.X and this allocation fails. If You are allocating memory in larger blocks it's possible that remaining memory is enough, but if You try various larger values You may hit situation when again throwing bad_alloc fails. If You try to do allocate 22,23, ... longs at time, I'm almost sure You'll find larger values You'll get SIGABRT again About new1.cc - it's in gcc2953s.zip: see gnu/gcc-2.953/gcc/cp/new1.cc but I don't recommend to mess much with it. It's possible to solve such problem without messing with new1.cc (using set_new_handler()) Andris