Mail Archives: djgpp/2001/05/07/02:01:17
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
- Raw text -