help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: g++ 3.4.1 core dump with -O2


From: Guy Harrison
Subject: Re: g++ 3.4.1 core dump with -O2
Date: Wed, 14 Jul 2004 04:00:31 GMT
User-agent: KNode/0.7.7

Ralf Fassel wrote:

> Hi all,
> g++ 3.4.1 on IRIX 6.5.15m, core dump when compiling our program with
> -O2 (or any level of optimization).
> 
> % g++ -v
> Reading specs from
> /disk1/software/gcc/3.4.1/IRIX-6/bin/../lib/gcc/mips-sgi-irix6.5/3.4.1/specs
> Configured with: /disk4/tmp/ralf/Software/gcc-3.4.1/configure
> --prefix=/software/gcc/3.4.1 --exec-prefix=/software/gcc/3.4.1/IRIX-6
> --with-local-prefix=/work --enable-languages=c,c++ --enable-shared
> --disable-multilib : (reconfigured)
> /hosts/jupiter/disk4/tmp/ralf/Software/gcc-3.4.1/configure
> --prefix=/software/gcc/3.4.1 --exec-prefix=/software/gcc/3.4.1/IRIX-6
> --with-local-prefix=/work --enable-languages=c,c++ --enable-shared
> --disable-multilib : (reconfigured)
> /hosts/jupiter/disk4/tmp/ralf/Software/gcc-3.4.1/configure
> --prefix=/software/gcc/3.4.1 --exec-prefix=/software/gcc/3.4.1/IRIX-6
> --with-local-prefix=/work --enable-languages=c,c++ --enable-shared
> --disable-multilib Thread model: single gcc version 3.4.1
> 
> We have a nasty coredump which occurs at all optimization level -O --
> -O3, but is not present at -O0/-g.  It happens when our code executes
>     new foo*[0]
^^^
That's okay. C++ ought to receive a unique pointer for each new[0] and
consequently you must delete[] it.

> i.e. tries to allocate an array of pointers of size 0.  The same call
> executes several times w/o problems, and then reproducibly crashes on
> the same code position.  Other programs use the same library calls and
> do not crash at that position.
> 
> Unfortunately gdb is not of much help (5.3 and 6.1.1), since it can't
> make anything out of the stack in the core dump:
>     Core was generated by `fweightx'.
>     Program terminated with signal 10, Bus error.
>     Reading symbols from
>     /homes/ulrike/si++.4.0.C198/lib/mips/libsimath.so...done. Loaded
>     symbols for /homes/ulrike/si++.4.0.C198/lib/mips/libsimath.so Reading
>     symbols from /homes/ulrike/si++.4.0.C198/lib/mips/libsi++.so...done.
>     Loaded symbols for /homes/ulrike/si++.4.0.C198/lib/mips/libsi++.so
>     Reading symbols from
>     /homes/ulrike/si++.4.0.C198/lib/mips/libhdio.so...done. Loaded symbols
>     for /homes/ulrike/si++.4.0.C198/lib/mips/libhdio.so Reading symbols
>     from /homes/ulrike/si++.4.0.C198/lib/mips/libstdc++.so.7...done.
>     Loaded symbols for /homes/ulrike/si++.4.0.C198/lib/mips/libstdc++.so.7
>     Reading symbols from /usr/lib32/libmx.so...done. Loaded symbols for
>     /usr/lib32/libmx.so Reading symbols from /usr/lib32/libm.so...done.
>     Loaded symbols for /usr/lib32/libm.so Reading symbols from
>     /homes/ulrike/si++.4.0.C198/lib/mips/libgcc_s.so.1...done. Loaded
>     symbols for /homes/ulrike/si++.4.0.C198/lib/mips/libgcc_s.so.1 Reading
>     symbols from /usr/lib32/libc.so.1...done. Loaded symbols for
>     /usr/lib32/libc.so.1 Reading symbols from /usr/lib32/libfpe.so...done.
>     Loaded symbols for /usr/lib32/libfpe.so
>     #0  0x0fa3a8bc in _aio_realloc_fds () at ainit.c:160
>     160       ainit.c: No such file or directory.
>             in ainit.c
>     (gdb) where
>     where
>     #0  0x0fa3a8bc in _aio_realloc_fds () at ainit.c:160
>     #1  0x0fa3a774 in _aio_sgi_init () at ainit.c:96
>     warning: Warning: GDB can't find the start of the function at 0x809.
> 
>         GDB is unable to find the start of the function at 0x809
>     and thus can't determine the size of that function's stack frame.
>     This means that GDB may be unable to access that stack frame, or
>     the frames below it.
>         This problem is most likely caused by an invalid program counter
>         or
>     stack pointer.
> 
> The code right before the crash is
> 
>     std::cerr << "a1d:: " << (void*)this << " length/1, oldlen " <<
>         len << " newlen " << newlen << std::endl;
>     type **nv = new type* [newlen];
>     std::cerr << "a1d:: new DONE " << (void*)this << std::endl;
> 
> I can set a breakpoint at the middle line and confirm that newlen is
> 0 (non-negative).  Nevertheless the crash at `next' in the debugger
> happens, and gdb can't `up' back to that code position.

Unfortunately the C++ new[0]/delete[] behaviour does not work itself down to
C malloc/calloc/realloc level. I'm getting rusty at this stuff but at C
level ?alloc(0) is implementation defined. These days one can be pretty
certain of realloc() behaviour, plus logic dictates calloc(0,0) would be
best served mimicking new[0]/delete[]. Older malloc(0) implementations
would probably have yielded unique pointer also (due to how their "arenas"
were implemented, ie...

malloc(ZERO) = OS_malloc(sizeof(area_header) + ZERO))

Now the rusty bit. I think c99 disallows such a pointer. That's to say
whereas malloc(0) may well return a unique pointer whose value could
formally be passed around (and subsequently free()'d), c99 disallows the
value in the pointer itself...

<old>
char *p=malloc(0);      //oki
*p = 0;                 //bad
free(p);                //?oki?
</old>

<c99>
char *p=malloc(0);      //?oki?
*p=0;                   //bad
free(p)                 //bad
</c99>

> I have tried to attach the dmalloc library, but if I use it in every
> module, the error does not happen any longer.  Also no problems are
> detected by dmalloc.

Check you don't have any ?alloc calls in your own code which might be
suspect due to above. Hopefully you have, or some other cockpit corruption.
Otherwise you're faced with a new[0]/delete[] bug which, because the
underlying C stuff is implementation defined, could lie anywhere from
inside gcc itself (ontopic), "libc" (offtopic), downward (offtopic).

> Since I would like to compile the library with -O (the same code runs
> ok on HP with g++ 3.4.1, and on Windows using the 2003 .net compiler),
> I would like to eliminate this problem :-/
> 
> Anybody any tips how to proceed further?

Code snippet if possible? std::auto_ptr<> ?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]