Mail Archives: djgpp/2001/05/05/13:05:58
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 ?
> If I compile slightly modified example with gcc-3.0 development
> version (20010503) exception is catched also when I'm trying to
> allocating 4 bytes each time
>
> Andris
>
> On 4 May 2001, at 15:13, Dennis Yelle wrote:
>
> > When I compile and run this program:
> > ====================================
> > #include <memory>
> > #include <iostream>
> >
> > int main()
> > {
> > cout << "testing new long.\n";
> > int count = 0;
> > for(;;) {
> > long* p;
> > try {
> > //p = new(nothrow) long;
> > p = new long;
> > } catch (...) {
> > return 99;
> > }
> > if ( !p )
> > return 88;
> > count++;
> > if ( 0 == count % 200000)
> > cout << "I got " << count << " longs.\n";
> > }
> > cout << "I got " << count << " longs.\n";
> > }
> > ====================================
> > I get a stack dump, and when I symify it, I get:
> >
> > Call frame traceback EIPs:
> > 0x00013454 ___djgpp_traceback_exit+48
> > 0x00013536 _raise+94
> > 0x000128bb _abort+27
> > 0x0000d7eb ___default_terminate+11, line 0 of libgcc2.c
> > 0x0000e27d _terminate__Fv+13, line 0 of exception.cc
> > 0x0000e32a ___eh_alloc+30, line 0 of exception.cc
> > 0x0000d72d ___builtin_new+65, line 0 of new1.cc
> > 0x000015ca _main+42
> > 0x00010992 ___crt1_startup+178
> >
> > When new fails, it is supposed to throw an exception that
> > can be caught with
> > catch(...)
> > But it does not do so.
> > Symify leads me to think that the problem is in new1.cc
> > I am trying to find the file new1.cc
> > It is NOT in DJLSR203.ZIP and it is not in GCC2953B.ZIP
> > Can anyone tell me where to find the source file new1.cc ?
> >
> > Also, it looks like new long usually allocates 24 bytes
> > per requested long. This seems excessive to me.
> > Does anyone know why it should do this?
> >
> > Dennis Yelle
> > --
> > I am a computer programmer and I am looking for a job.
> > There is a link to my resume here:
> > http://table.jps.net/~vert/
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
- Raw text -