Problem with -stack-list-frames

Problem with -stack-list-frames

[Dmitry Smirnov]

Hi,

I was using gdb-6.8.50.20080630 for a while in the following configuration:
- Eclipse CDT as a front end,
- gdb-6.8.50.20080630 as ARM debugger connected to skyeye simulator
- skyeye simulator as a remote target (server)

It was working fine till I had tried to swicth to another (modern) way in CDT debug configuration (called DSF).

With the guys that support this new feature, we found that gdb does not respond correctly to -stack-list-frames command.

Here is the output, I got from gdb (plus few more commands):

info threads
* 1 Thread <main>  tmc_init () at qct\services\tmc\tmc.c:11541
warning: RMT ERROR : failed to get remote thread list.
-stack-list-frames

bt
#0  tmc_init () at qct\services\tmc\tmc.c:11541
#1  0x00c1d4c6 in tmc_task (ignored=<value optimized out>)
   at qct\services\tmc\tmc.c:12350
#2  0x00eee43e in rex_thread_init (entrypoint=0xc1d4a9 <tmc_task+1>)
   at qct\services\rexl4\rexl4.c:174
#3  0x00f3e0c8 in __thread_stub ()
#4  0x00f3e0c8 in __thread_stub ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

As you can see, info threads and bt works as expected.

Don't you know what could be the reason for such a silence of -stack-list-frames?
Could you please tell where can start debugging GDB to catch the root cause?

BTW, in case you would find it usefull to read the CDT maillist topic, see http://dev.eclipse.org/mhonarc/lists/cdt-
dev/msg14275.html

Dmitry

Re: Problem with -stack-list-frames

[Vladimir Prus]

Dmitry Smirnov wrote:

> Hi,
> 
> I was using gdb-6.8.50.20080630 for a while in the following configuration:
> - Eclipse CDT as a front end,
> - gdb-6.8.50.20080630 as ARM debugger connected to skyeye simulator
> - skyeye simulator as a remote target (server)
> 
> It was working fine till I had tried to swicth to another (modern) way in CDT debug configuration
> (called DSF).
> 
> With the guys that support this new feature, we found that gdb does not respond correctly to
> -stack-list-frames command.
> 
> Here is the output, I got from gdb (plus few more commands):
> 
> info threads
> * 1 Thread <main>  tmc_init () at qct\services\tmc\tmc.c:11541
> warning: RMT ERROR : failed to get remote thread list.
> -stack-list-frames
> 
> bt
> #0  tmc_init () at qct\services\tmc\tmc.c:11541
> #1  0x00c1d4c6 in tmc_task (ignored=<value optimized out>)
>    at qct\services\tmc\tmc.c:12350
> #2  0x00eee43e in rex_thread_init (entrypoint=0xc1d4a9 <tmc_task+1>)
>    at qct\services\rexl4\rexl4.c:174
> #3  0x00f3e0c8 in __thread_stub ()
> #4  0x00f3e0c8 in __thread_stub ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> As you can see, info threads and bt works as expected.

Please enable the verbose mode in the console -- there's a button in the
toolbar. This will tell exactly what the error is -- and I'm 51% sure
the problem is that you are trying to send MI command, and DSF thinks it's
CLI command, and sends something not right.

And this might be unrelated to whatever problem you are having in the first
place. CDI  debuggers have a way to enable verbose console mode in the
launch configuration. Please do that in DSF and then see if something
is wrong with any GDB response.

- Volodya

Re: Problem with -stack-list-frames

[Daniel Jacobowitz]

On Wed, Feb 11, 2009 at 09:57:15PM +0300, Vladimir Prus wrote:
> > -stack-list-frames
> > 
> > bt
> > #0  tmc_init () at qct\services\tmc\tmc.c:11541
> > #1  0x00c1d4c6 in tmc_task (ignored=<value optimized out>)
> >    at qct\services\tmc\tmc.c:12350
> > #2  0x00eee43e in rex_thread_init (entrypoint=0xc1d4a9 <tmc_task+1>)
> >    at qct\services\rexl4\rexl4.c:174
> > #3  0x00f3e0c8 in __thread_stub ()
> > #4  0x00f3e0c8 in __thread_stub ()
> > Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> > 
> > As you can see, info threads and bt works as expected.
> 
> Please enable the verbose mode in the console -- there's a button in the
> toolbar. This will tell exactly what the error is -- and I'm 51% sure
> the problem is that you are trying to send MI command, and DSF thinks it's
> CLI command, and sends something not right.

Another possible problem is PR 9500, which I analyzed but never
fixed...

-- 
Daniel Jacobowitz
CodeSourcery

RE: Re: Problem with -stack-list-frames

[Marc Khouzam]

 
> From: Vladimir Prus
> Sent: Wednesday, February 11, 2009 1:57 PM
> To: gdb@sources.redhat.com
> Subject: Re: Problem with -stack-list-frames
> 
> Please enable the verbose mode in the console -- there's a 
> button in the
> toolbar. This will tell exactly what the error is -- and I'm 51% sure
> the problem is that you are trying to send MI command, and 
> DSF thinks it's
> CLI command, and sends something not right.
> 
> And this might be unrelated to whatever problem you are 
> having in the first
> place. CDI  debuggers have a way to enable verbose console mode in the
> launch configuration. Please do that in DSF and then see if something
> is wrong with any GDB response.

Yeah... I didn't get to implementing the verbose console yet :-(
But I've been feeling the pressure for it so I've bumped it up on my
todo list.

You can still get traces by launching eclipse with 
-debug ~/dsf.debug.options

where dsf.debug.options contains

org.eclipse.dd.mi/debug = true
org.eclipse.cdt.dsf.gdb/debug = true

RE: Re: Problem with -stack-list-frames

[Marc Khouzam]

I just realized something, please see below. 

> -----Original Message-----
> From: Marc Khouzam 
> Sent: Wednesday, February 11, 2009 2:09 PM
> To: 'Vladimir Prus'; 'gdb@sources.redhat.com'
> Subject: RE: Re: Problem with -stack-list-frames
> 
>  
> > From: Vladimir Prus
> > Sent: Wednesday, February 11, 2009 1:57 PM
> > To: gdb@sources.redhat.com
> > Subject: Re: Problem with -stack-list-frames
> > 
> > Please enable the verbose mode in the console -- there's a 
> > button in the
> > toolbar. This will tell exactly what the error is -- and 
> I'm 51% sure
> > the problem is that you are trying to send MI command, and 
> > DSF thinks it's
> > CLI command, and sends something not right.

DSF sends it correctly but the output is not shown in the console
that is why it seems blank.  You need the traces to see the
output.  See previous mail (or below) to turn them on.

I'm gonna have to have DSF-GDB print the output of console
commands to the console....


> > 
> > And this might be unrelated to whatever problem you are 
> > having in the first
> > place. CDI  debuggers have a way to enable verbose console 
> mode in the
> > launch configuration. Please do that in DSF and then see if 
> something
> > is wrong with any GDB response.
> 
> Yeah... I didn't get to implementing the verbose console yet :-(
> But I've been feeling the pressure for it so I've bumped it up on my
> todo list.
> 
> You can still get traces by launching eclipse with 
> -debug ~/dsf.debug.options
> 
> where dsf.debug.options contains
> 
> org.eclipse.dd.mi/debug = true
> org.eclipse.cdt.dsf.gdb/debug = true
> 
>