mystery backtrace

mystery backtrace

[Jim Watson]

this is from openoffice.org 680 on linux sparc

Any advice would be appreciated, is this valid output of the "list" command
[1], and what can i do next?

0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
(gdb) list
1       /build/buildd/glibc-2.3.2.ds1/build-tree/sparc-libc/csu/crti.S: No
such file or directory.
        in /build/buildd/glibc-2.3.2.ds1/build-tree/sparc-libc/csu/crti.S
(gdb)


thanks

jim

[1] Full report follows:

jim@sun:~/680/cppu/unxlngs.pro/bin$ gdb ./testcppu
GNU gdb 2003-09-18-cvs
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-unknown-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /home/jim/680/cppu/unxlngs.pro/bin/testcppu 
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 7542)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 7542)]
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
(gdb) list
1       /build/buildd/glibc-2.3.2.ds1/build-tree/sparc-libc/csu/crti.S: No
such file or directory.
        in /build/buildd/glibc-2.3.2.ds1/build-tree/sparc-libc/csu/crti.S
(gdb) 

Re: mystery backtrace

[Keith M Wesolowski]

On Thu, May 13, 2004 at 08:04:58AM +1000, Jim Watson wrote:

> this is from openoffice.org 680 on linux sparc
> 
> Any advice would be appreciated, is this valid output of the "list" command
> [1], and what can i do next?
> 
> 0x00000000 in ?? ()
> (gdb) where
> #0  0x00000000 in ?? ()
> (gdb) list
> 1       /build/buildd/glibc-2.3.2.ds1/build-tree/sparc-libc/csu/crti.S: No
> such file or directory.
>         in /build/buildd/glibc-2.3.2.ds1/build-tree/sparc-libc/csu/crti.S

No, the program has for some reason jumped to NULL.  You need a full
backtrace if you can get one.  If not, your registers are trashed as
well, and you'll have to use breakpoints or some other method to catch
it before it happens.  It shows you crti.S because the lowest address
in the binary (closest to the 0x0 shown) is in that standard C runtime.

-- 
Keith M Wesolowski