arm-elf-gdb crash

arm-elf-gdb crash

[Shaun Jackman]

arm-elf-gdb 6.2.1 crashed after issuing a 'step' command. Here's the
commands leading up to it and the backtrace.

Cheers,
Shaun

$ arm-elf-gdb --version
GNU gdb 6.2.1
...
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
$ arm-elf-gdb hello
(gdb) target remote bdi:2001
0x02020974 in ?? ()
(gdb) lo
Loading section .text, size 0x1edc lma 0x2080000
Loading section .init, size 0x14 lma 0x2081edc
Loading section .fini, size 0x10 lma 0x2081ef0
Loading section .rodata, size 0x1e lma 0x2081f00
Loading section .eh_frame, size 0x4 lma 0x2081f20
Loading section .ctors, size 0x8 lma 0x2082024
Loading section .dtors, size 0x8 lma 0x208202c
Loading section .jcr, size 0x4 lma 0x2082034
Loading section .data, size 0x81c lma 0x2082038
Start address 0x2080000, load size 10066
Transfer rate: 80528 bits/sec, 251 bytes/write.
(gdb) b main
Breakpoint 1 at 0x208014c: file hello.c, line 8.
(gdb) c
Continuing.

Breakpoint 1, main () at hello.c:8
8       }
(gdb) s
Segmentation fault (core dumped)

$ gdb arm-elf-gdb core
(gdb) bt
#0  0x0808ba69 in get_frame_pc (frame=0x0) at ../../gdb/frame.c:1886
#1  0x080f9e8d in insert_step_resume_breakpoint (return_frame=0x0,
    ecs=0xbfffee50) at ../../gdb/infrun.c:2684
#2  0x080f8f3d in handle_inferior_event (ecs=0xbfffee50)
    at ../../gdb/infrun.c:1984
#3  0x080f85dc in wait_for_inferior () at ../../gdb/infrun.c:998
#4  0x080f83f5 in proceed (addr=1, siggnal=TARGET_SIGNAL_DEFAULT, step=1)
    at ../../gdb/infrun.c:821
#5  0x080f56b5 in step_1 (skip_subroutines=0, single_inst=0, count_string=0x0)
    at ../../gdb/infcmd.c:688
#6  0x080f54df in step_command (count_string=0x0, from_tty=1)
    at ../../gdb/infcmd.c:577
#7  0x080a9419 in do_cfunc (c=0x0, args=0x0, from_tty=0)
    at ../../gdb/cli/cli-decode.c:57
#8  0x080ab37c in cmd_func (cmd=0x82c4768, args=0x0, from_tty=0)
    at ../../gdb/cli/cli-decode.c:1561
#9  0x080836cd in execute_command (p=0x82af071 "", from_tty=1)
    at ../../gdb/top.c:744
#10 0x081056ff in command_handler (command=0x82af070 "s")
    at ../../gdb/event-top.c:500
#11 0x08105b45 in command_line_handler (rl=0x832a040 "")

Re: arm-elf-gdb crash

[Daniel Jacobowitz]

On Thu, May 05, 2005 at 08:26:59PM -0700, Shaun Jackman wrote:
> arm-elf-gdb 6.2.1 crashed after issuing a 'step' command. Here's the
> commands leading up to it and the backtrace.

This bug report is still not especially useful, without a reproducible
test case.  All I can do is recommend you try a current version.
There have been plenty of bug fixes since 6.2.1.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: arm-elf-gdb crash

[Shaun Jackman]

On 5/5/05, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, May 05, 2005 at 08:26:59PM -0700, Shaun Jackman wrote:
> > arm-elf-gdb 6.2.1 crashed after issuing a 'step' command. Here's the
> > commands leading up to it and the backtrace.
> 
> This bug report is still not especially useful, without a reproducible
> test case.  All I can do is recommend you try a current version.
> There have been plenty of bug fixes since 6.2.1.

I've been having trouble with recent versions of gdb. 6.3 fails while loading:

(gdb) load
Loading section .text, size 0x64a8 lma 0x2000000
Memory access error while loading section .text.

6.3.50.20050419 fixes the load bug, but fails when setting the $cpsr
(gdb) set $cpsr=0x1f
Value being assigned to is no longer active.

Do you know if the $cpsr bug has been fixed in a recent snapshot?

Cheers,
Shaun

Re: arm-elf-gdb crash

[Daniel Jacobowitz]

On Thu, May 05, 2005 at 08:49:00PM -0700, Shaun Jackman wrote:
> On 5/5/05, Daniel Jacobowitz <drow@false.org> wrote:
> > On Thu, May 05, 2005 at 08:26:59PM -0700, Shaun Jackman wrote:
> > > arm-elf-gdb 6.2.1 crashed after issuing a 'step' command. Here's the
> > > commands leading up to it and the backtrace.
> > 
> > This bug report is still not especially useful, without a reproducible
> > test case.  All I can do is recommend you try a current version.
> > There have been plenty of bug fixes since 6.2.1.
> 
> I've been having trouble with recent versions of gdb. 6.3 fails while loading:
> 
> (gdb) load
> Loading section .text, size 0x64a8 lma 0x2000000
> Memory access error while loading section .text.

Fixed after 6.3, yes.

> 6.3.50.20050419 fixes the load bug, but fails when setting the $cpsr
> (gdb) set $cpsr=0x1f
> Value being assigned to is no longer active.
> 
> Do you know if the $cpsr bug has been fixed in a recent snapshot?

I discussed this with someone else on this list last week.  It is an
open bug but someone needs to sit down with it and think about the
implications.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: arm-elf-gdb crash

[Shaun Jackman]

On 5/5/05, Daniel Jacobowitz <drow@false.org> wrote:
> > 6.3.50.20050419 fixes the load bug, but fails when setting the $cpsr
> > (gdb) set $cpsr=0x1f
> > Value being assigned to is no longer active.
> >
> > Do you know if the $cpsr bug has been fixed in a recent snapshot?
> 
> I discussed this with someone else on this list last week.  It is an
> open bug but someone needs to sit down with it and think about the
> implications.

The implications meaning the possible causes, or the implications of
possible solutions?

> I suspect that we've failed to create the first frame, somehow.

Perhaps this would only defer the problem, but in the case of
assigning to a register that's never going away, could we skip the
check for a valid frame and plow ahead and write the register?

Cheers,
Shaun

Re: arm-elf-gdb crash

[Daniel Jacobowitz]

On Fri, May 06, 2005 at 08:40:00AM -0700, Shaun Jackman wrote:
> On 5/5/05, Daniel Jacobowitz <drow@false.org> wrote:
> > > 6.3.50.20050419 fixes the load bug, but fails when setting the $cpsr
> > > (gdb) set $cpsr=0x1f
> > > Value being assigned to is no longer active.
> > >
> > > Do you know if the $cpsr bug has been fixed in a recent snapshot?
> > 
> > I discussed this with someone else on this list last week.  It is an
> > open bug but someone needs to sit down with it and think about the
> > implications.
> 
> The implications meaning the possible causes, or the implications of
> possible solutions?

The latter.

> > I suspect that we've failed to create the first frame, somehow.
> 
> Perhaps this would only defer the problem, but in the case of
> assigning to a register that's never going away, could we skip the
> check for a valid frame and plow ahead and write the register?

GDB associates registers to frames.  It's written to the assumption
that there is always a frame; when there isn't, this is just one of
many things that is going to go wrong.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: arm-elf-gdb crash

[Shaun Jackman]

On 5/6/05, Daniel Jacobowitz <drow@false.org> wrote:
> GDB associates registers to frames.  It's written to the assumption
> that there is always a frame; when there isn't, this is just one of
> many things that is going to go wrong.

When the target's gone toes-up like this, normally I don't want to do
any further source-level debugging. I'm more interested in peeking and
poking a few registers to do some post-mortem analysis before I reload
the target. When a frame isn't available, could GDB fall back to a set
of global registers?

Cheers,
Shaun

Re: arm-elf-gdb crash

[Shaun Jackman]

2005/5/6, Shaun Jackman <sjackman@gmail.com>:
> On 5/6/05, Daniel Jacobowitz <drow@false.org> wrote:
> > GDB associates registers to frames.  It's written to the assumption
> > that there is always a frame; when there isn't, this is just one of
> > many things that is going to go wrong.
> 
> When the target's gone toes-up like this, normally I don't want to do
> any further source-level debugging. I'm more interested in peeking and
> poking a few registers to do some post-mortem analysis before I reload
> the target. When a frame isn't available, could GDB fall back to a set
> of global registers?
> 
> Cheers,
> Shaun

Hello,

This is a quick poll to see if there's been any movement on the "Value
being assigned to is no longer active." bug. It haunts me daily.

(gdb) set $cpsr=0x1f
Value being assigned to is no longer active.

Cheers!
Shaun