Re: [uClinux-dev] m68k gdb server mi crashes uclinux

[NZG <ngustavson at emacinc dot com>]

Digging deeper, it appears that this only happens if the debugger starts 
trying to parse through frames before the program begins executing (i.e. a 
remote connection is made but no breakpoint is specified and continue is 
never called)

In this case gdbserver appears to just be continually feeding random numbers 
back, you get this same effect from the command line by running backtrace 
before calling continue.

This appears to be erronous on gdbservers side, I'll continue to dig.

NZG.



On Thursday 19 January 2006 4:40 pm, NZG wrote:
> Hi Mike,
> thanks for the tip!
>
> Problem is, high level debuggers (as I'm sure your aware) may not bother to
> include a depth, in order to retrieve the total depth of the stack.
> gdbserver/uClinux does not seem to like this.
> Does this have something to do with it not having an MMU?
>
> I could certainly patch gdb's mi interface to restrict the depth in can
> search when no arguement is passed, but I would like to figure out if
> that's really necessary first.
>
> thx
> NZG.
>
> On Thursday 19 January 2006 4:25 pm, Mike Lavender wrote:
> > Hi NZG,
> >
> > > However, when I use the MI command to retrieve the stack depth:
> > >
> > > -stack-info-depth
> > >
> > > This call takes some time, then returns with a -1 and causes gdbserver
> > > to smash the OS to bits.
> > >
> > > gdbserver :6000 test_target  2 3
> > > Process test_target created; pid = 112
> > > code at 0x810040 - 0x813940, data at 0x813944
> > > Remote debugging using :6000
> > > ad page state at free_hot_cold_page (in process 'gdbserver', page
> > > 00327300)
> > > flags:0x20001000 mapping:00000000 mapcount:0 count:0
> > > Backtrace:
> > > Stack from 00a3af08:<0>
> > >        <0> 00a3af18<0> 00a3af90<0> 0002f418<0> 000ebef9<0> 00327300<0>
> > > 00000000<0> 0002f>
> > >        <0> 00327300<0> 00000004<0> 00c29260<0> 00327300<0> 0011032c<0>
> > > 0002f9c6<0> 00327>
> > >        <0> 00033e54<0> 00327300<0> 00c29260<0> 00a3afc0<0> 00fcf340<0>
> > > 0001ccba<0> 00327>
> > >        <0> 00000000<0> 00000001<0> 00000070<0> 00000000<0> 00000001<0>
> > > 00fcf340<0> 00944>
> > >        <0> 00327300<0> 001308b8<0> 00a3afc4<0> 000110c6<0> 00fcf340<0>
> > > 00818010<0> 00a3a>
> > >        <0> 00000000<0> 00a3a000<0> 00010fce<0> 0080fe94<0> 0080fe94<0>
> > > 00944230<0> 59e70>
> > > Call Trace:<0>
> > >        <0> [<00013a0a>]<0>
> > > Trying to fix it up, but a reboot is needed
> > >
> > >
> > > I suspect it's running through it's memory and into something
> > > else, but some
> > > deep ugly gdb debugging is going to be required.
> > >
> > > Somebody please tell me there is a patch for this.
> > > If not, any tips you might have would be appreciated.
> > >
> > > thx,
> > > NZG
> >
> > The -stack-info-depth command takes an optional argument [max_depth]
> > which will limit how far it goes.
> >
> > see here
> > http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC481 for
> > info on the mi stack commands.
> >
> >
> > Mike
> >
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev@uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev@uclinux.org
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org