can't backtrace assert(0) with new/delete

can't backtrace assert(0) with new/delete

Post by David H » Thu, 27 Jan 2000 04:00:00



The following problem occurs in
solaris 7 running g++ 2.95.2

venus(8)$ uname -a
SunOS venus 5.7 Generic_106541-02 sun4u sparc SUNW,Ultra-5_10
venus(9)$ g++ -v
Reading specs from
/vol/gnu/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
gcc version 2.95.2 19991024 (release)

#include <assert.h>

void func2()
{
  assert(0);

Quote:}

void func1()
{
  func2();

Quote:}

int main()
{
  //  int *pi = new int;
  func1();
  //  delete pi;

Quote:}

when running, gdb stop when assert failed
if you backtrace (bt or where)
(gdb) where
#0  0xff3169c0 in _libc_kill () from /usr/lib/libc.so.1
#1  0xff2b9340 in abort () from /usr/lib/libc.so.1
#2  0x10ae0 in Letext ()
#3  0x10a34 in func2__Fv () at bt.c:5
#4  0x10a58 in func1__Fv () at bt.c:10
#5  0x10a7c in main () at bt.c:16

which is good, I can move up frame until my source

but if I keep the new and delete
int main()
{
  int *pi = new int;
  func1();
  delete pi;

Quote:}

(gdb) where
#0  0xff3169c0 in _libc_kill () from /usr/lib/libc.so.1
#1  0xff2b9340 in abort () from /usr/lib/libc.so.1
#2  0x13a2c in __builtin_delete (ptr=0xff332110)

I can no longer move up to my source

what is this __builtin_delete?
is this behavior normal?

by the way, there is no problem in my linux box.

mars(1)$ uname -a
Linux mars 2.2.14 #5 Sat Jan 15 21:53:24 PST 2000 i686 unknown
mars(2)$ g++ -v
Reading specs from
/vol/gnu/gcc/2.95.2/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)

 
 
 

1. Interpreting the results from backtrace()/ backtrace() usability

I've got the following output from backtrace_symbols_fd():

(There are a ton of [0x0]s in the beginning of the file)

...
[0x0]
[0x0]
[0x14000000]
/usr/local/sbin/lockmgr.4.5
[0x42029188]
[0x2e320000]
/usr/local/sbin/lockmgr.4.5
[0x804a758]
[0x2000]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]

...

[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x0]
[0x10000000]
/lib/ld-linux.so.2[0x40000812]
/usr/local/sbin/lockmgr.4.5[0x4201033a]
[0x4002c1a0]
/lib/ld-linux.so.2(_dl_lookup_versioned_symbol+0x11)[0x40007641]
[0x55a36f5]
/usr/local/sbin/lockmgr.4.5[0x804a7c7]
[0x3]
[0xbfffdef0]
[0xbfffdc0c]
/usr/local/sbin/lockmgr.4.5[0x804a7b7]
[0xe]
/usr/local/sbin/lockmgr.4.5[0x804a758]
[0xbfffdc0c]
/usr/local/sbin/lockmgr.4.5[0x804a7a8]
[0xc]
/lib/ld-linux.so.2[0x400005b8]
/lib/ld-linux.so.2[0x40000218]
/lib/ld-linux.so.2(_rtld_global+0x1c8)[0x400131e8]
[0x4]
[0x4002c294]
[0xbfffdf08]
/usr/local/sbin/lockmgr.4.5
[0x42029188]

I seem to be able to crossreference some 0x8???????es to the output of
nm. But what about the rest? The executable is compiled with debug info.

2. VI Editor Question

3. Getting unresolved symbols for 'new' and 'delete' operators

4. case sensitivity in log files

5. GNU Compiler

6. Allowing non-root to shutdown

7. undefined reference to 'assert'

8. 'delete' command in ftp delete files in local hard disk ???

9. It's not bad canned meat...

10. resend of reply (it's really a new question) to how to delete a line