gdb 6.0 backtrace on Solaris 5.8

gdb 6.0 backtrace on Solaris 5.8

[Klaus Zeitler]

I'm using gdb 6.0 on solaris 5.8 and I'm having problems with the backtrace
that gdb 6.0 shows. 'bt' sometimes doesn't show all the calls. I've tried
a few small example programs, but couldn't reproduce it there :-(.
Today I tried to look at an emacs (CVS version) crash and here gdb 6.0 refused
to show any backtrace at all:

gdb 6.0 shows:

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()


whereas gdb 5.3 shows:

(gdb) bt
#0  0x00000000 in ?? ()
#1  0xfee5e4bc in XRegisterIMInstantiateCallback () from /usr/lib/libX11.so.4
#2  0x00134804 in xim_initialize (dpyinfo=0x81c800, 
    resource_name=0x7c4154 "emacs")
    at /vol/freeware/cvs/emacs/head/emacs/src/xterm.c:8178
#3  0x0013aba0 in x_term_init (display_name=1618729156, xrm_option=0x0, 
    resource_name=0x7c4154 "emacs")
    at /vol/freeware/cvs/emacs/head/emacs/src/xterm.c:10604
#4  0x00146af8 in Fx_open_connection (display=1618729156, 
    xrm_string=542359556, must_succeed=542359604)
    at /vol/freeware/cvs/emacs/head/emacs/src/xfns.c:4183
#5  0x0023cec8 in Ffuncall (nargs=4, args=0xffbed3d8)
    at /vol/freeware/cvs/emacs/head/emacs/src/eval.c:2735
#6  0x0029e450 in Fbyte_code (bytestr=1618727748, vector=-2140932608, 
    maxdepth=6) at /vol/freeware/cvs/emacs/head/emacs/src/bytecode.c:689
#7  0x0023b60c in Feval (form=-1603144640)
    at /vol/freeware/cvs/emacs/head/emacs/src/eval.c:2086
#8  0x00267160 in readevalloop (readcharfun=542497612, stream=0x533f18, 
    sourcename=1619044260, evalfun=0x23af08 <Feval>, printflag=0, 
    unibyte=542359556, readfun=542359556)
    at /vol/freeware/cvs/emacs/head/emacs/src/lread.c:1376
#9  0x002656c0 in Fload (file=1619044260, noerror=542359556, 
    nomessage=542359604, nosuffix=542359556, must_suffix=542359556)
    at /vol/freeware/cvs/emacs/head/emacs/src/lread.c:914
#10 0x0023cf68 in Ffuncall (nargs=4, args=0xffbed9e8)
    at /vol/freeware/cvs/emacs/head/emacs/src/eval.c:2744
#11 0x0029e450 in Fbyte_code (bytestr=1614584644, vector=-2143511692, 
    maxdepth=4) at /vol/freeware/cvs/emacs/head/emacs/src/bytecode.c:689
#12 0x0023b60c in Feval (form=-1606640844)
...


Any ideas? Thanks.

Klaus

-- 
 ------------------------------------------
|  Klaus Zeitler      Lucent Technologies  |
|  Email:             kzeitler@lucent.com  |
 ------------------------------------------
---
One way to make your old car run better is to look up the price of a
new model.

Re: gdb 6.0 backtrace on Solaris 5.8

[Daniel Jacobowitz]

On Wed, Jan 14, 2004 at 01:25:43PM +0100, Klaus Zeitler wrote:
> 
> I'm using gdb 6.0 on solaris 5.8 and I'm having problems with the backtrace
> that gdb 6.0 shows. 'bt' sometimes doesn't show all the calls. I've tried
> a few small example programs, but couldn't reproduce it there :-(.
> Today I tried to look at an emacs (CVS version) crash and here gdb 6.0 refused
> to show any backtrace at all:

You'll want to try a CVS snapshot.  Mark has rewritten the SPARC port,
and also fixed a bug that caused backtraces to stop when PC == 0.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb 6.0 backtrace on Solaris 5.8

[Klaus Zeitler]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
    Daniel> 
    Daniel> On Wed, Jan 14, 2004 at 01:25:43PM +0100, Klaus Zeitler wrote:
    >> 
    >> I'm using gdb 6.0 on solaris 5.8 and I'm having problems with the
    >> backtrace that gdb 6.0 shows. 'bt' sometimes doesn't show all the
    >> calls. I've tried a few small example programs, but couldn't reproduce
    >> it there :-(.  Today I tried to look at an emacs (CVS version) crash
    >> and here gdb 6.0 refused to show any backtrace at all:
    Daniel> 
    Daniel> You'll want to try a CVS snapshot.  Mark has rewritten the SPARC
    Daniel> port, and also fixed a bug that caused backtraces to stop when PC
    Daniel> == 0.

got it, tried it and it looks good now. Thanks a lot

Klaus


-- 
 ------------------------------------------
|  Klaus Zeitler      Lucent Technologies  |
|  Email:             kzeitler@lucent.com  |
 ------------------------------------------
---
If you had to identify, in one word, the reason why the human race has not
and never will achieve its full potential, that word would be: "meetings"