C++ nothrow new() problem under Irix - SGI

This is a discussion on C++ nothrow new() problem under Irix - SGI ; I am trying to use nothrow new() and am encountering what seems to be a bug in the SGI/Irix C++ environment. The following program runs OK under Solaris and Linux, but dumps core at the delete[] statement under Irix. Is ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: C++ nothrow new() problem under Irix

  1. C++ nothrow new() problem under Irix

    I am trying to use nothrow new() and am encountering what seems
    to be a bug in the SGI/Irix C++ environment. The following
    program runs OK under Solaris and Linux, but dumps core at the
    delete[] statement under Irix. Is this really an SGI implementation bug,
    or have I done something stupid? (Other than trying to use nothrow
    new(), that is ;-) )

    #include
    #include

    std::nothrow_t NoThrow;

    class Junk {
    public:
    Junk();
    ~Junk();
    };

    Junk::Junk() {
    (void) fprintf(stderr, "constr\n"); (void) fflush(stderr);
    }

    Junk::~Junk() {
    (void) fprintf(stderr, "destr\n"); (void) fflush(stderr);
    }

    main() {
    Junk *jnk;

    if ((jnk= new(NoThrow) Junk[5]) == (Junk *) 0) {
    (void) fprintf(stderr, "memory allocation error\n");
    exit(-1);
    }

    delete[] jnk;
    }

    My debugger stack looks like this:

    _kill()
    _raise()
    abort()
    _array_pointer_not_from_vec_new()
    __array_delete_general2()
    __vec_delete2()
    main() <---- stopped on the delete[] statement

    If I use regular new() instead, i.e.,

    jnk= new Junk[5];

    then the delete[] works OK under Irix. Do I need to be using some
    special form of delete[] to indicate that the new() was called with
    nothrow? I have seen no documentation anywhere that indicates that
    I should, but maybe I am not looking in the right places.

    I also tried

    float *f;

    f= new(NoThrow) float[100];
    delete[] f;

    under Irix and that works OK. The problem seems to occur only when
    using delete[] on a non-primitive.

    Thanks!


    --
    Roger Davis
    University of Hawaii/SOEST
    rbd@NoSpamHere.hawaii.edu

  2. Re: C++ nothrow new() problem under Irix

    In article ,
    Roger Davis wrote:
    >I am trying to use nothrow new() and am encountering what seems
    >to be a bug in the SGI/Irix C++ environment. The following


    This is the subject of bug-id 862202.
    (We added your report to that bug.)

    Latest EDG front ends give a warning message about this
    source code of yours, but we are not yet sure if this
    warning is real or simply a mistaken (on our part)
    integration of EDG front-end source.

    I'm not a C++ language lawyer, but if I had to guess I'd guess
    this is likely our bug, either in our runtime or our integration
    of the EDG front end.

    Sorry.
    David Anderson [Not an official SGI spokesperson...]
    PS: google 'nothrow new' to find the gotw (Guru Of
    The Week) notes on nothrow. Before you use it too much :-)

    PPS: IRIX CC has -LANG:exceptions=OFF to turn C++
    into an older-style (before exceptions) so new returns 0
    on failure. In IRIX virtual swap (like in Linux)
    can mean malloc will succeed apparently but reference to
    the memory can fail (Irrelevant Historical note: IRIX created
    virtual swap before Linux had the concept).

  3. Re: C++ nothrow new() problem under Irix

    In article ,
    Roger Davis wrote:
    > I am trying to use nothrow new() and am encountering what seems
    > to be a bug in the SGI/Irix C++ environment. The following
    > program runs OK under Solaris and Linux, but dumps core at the
    > delete[] statement under Irix. Is this really an SGI implementation bug,
    > or have I done something stupid? (Other than trying to use nothrow
    > new(), that is ;-) )
    >
    > #include
    > #include
    >
    > std::nothrow_t NoThrow;
    >
    > class Junk {
    > public:
    > Junk();
    > ~Junk();
    > };
    >
    > Junk::Junk() {
    > (void) fprintf(stderr, "constr\n"); (void) fflush(stderr);
    > }
    >
    > Junk::~Junk() {
    > (void) fprintf(stderr, "destr\n"); (void) fflush(stderr);
    > }
    >
    > main() {
    > Junk *jnk;
    >
    > if ((jnk= new(NoThrow) Junk[5]) == (Junk *) 0) {
    > (void) fprintf(stderr, "memory allocation error\n");
    > exit(-1);
    > }
    >
    > delete[] jnk;
    > }
    >
    > My debugger stack looks like this:
    >
    > _kill()
    > _raise()
    > abort()
    > _array_pointer_not_from_vec_new()
    > __array_delete_general2()
    > __vec_delete2()
    > main() <---- stopped on the delete[] statement
    >
    > If I use regular new() instead, i.e.,
    >
    > jnk= new Junk[5];
    >
    > then the delete[] works OK under Irix. Do I need to be using some
    > special form of delete[] to indicate that the new() was called with
    > nothrow? I have seen no documentation anywhere that indicates that
    > I should, but maybe I am not looking in the right places.
    >
    > I also tried
    >
    > float *f;
    >
    > f= new(NoThrow) float[100];
    > delete[] f;
    >
    > under Irix and that works OK. The problem seems to occur only when
    > using delete[] on a non-primitive.


    This may be an issue with unsupported placement array new on
    an older compiler.

    Please provide the compiler/linker versions, and the c++_eoe
    and compiler_eoe versions, and the compile/link command.

    And the IRIX OS version (just because).

    Joe
    --
    ------------------------------------------------------------------------
    Joseph Michaud - SGI Apps Eng 978-562-8894 x483-8894 jmichaud@sgi.com

  4. Re: C++ nothrow new() problem under Irix

    > Please provide the compiler/linker versions, and the c++_eoe
    > and compiler_eoe versions, and the compile/link command.


    % CC -version
    MIPSpro Compilers: Version 7.3.1.3m

    % ld -V
    ld32: INFO 153: Version 7.30.

    c++_eoe 7.3.1.3m
    compiler_eoe 7.3.1.3m

    % CC -o junk -g junk.cc
    % ./junk
    constr
    constr
    constr
    constr
    constr
    Abort (core dumped)

    > And the IRIX OS version (just because).


    eoe IRIX Execution Environment, 6.5.16m

    (Thanks for looking into this, Joe.)

+ Reply to Thread