segmentation fault when debugging with gdb

Development Boards MicroMod
1

I’ve got the 0.1.0 release of OpenOCD and I’m seeing a segmentation fault after a couple steps with arm-elf-gdb. I wasn’t able to gather any useful information yet, when I run openocd in gdb it can’t find standard config files (some kind of environment problem). Anyone seen this before?

$ openocd -f ~/dev/ocd/openocd.cfg 
Open On-Chip Debugger 0.1.0 (2009-01-22-11:22) Release


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: https://kc8apf@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c $
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)
Info : JTAG Tap/device matched
Warn : no tcl port specified, using default port 6666
Warn : DBGACK set while target was in unknown state. Reset or initialize target.
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x00100c28
Info : accepting 'gdb' connection from 0
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)
Info : JTAG Tap/device matched
Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x200000d3 pc: 0x001000bc
core state: ARM
force hard breakpoints
Info : dropped 'gdb' connection - error -400
Info : accepting 'gdb' connection from 0
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)
Info : JTAG Tap/device matched
Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x200000d3 pc: 0x001000bc
Segmentation fault
2

hi,

the same thing happened to me on my board with gdb but i figured out the solution and its working fine for me. i cannot give you any suggestions right away because the information from ur post is not enough except ur target is ARM. if you could provide some more information then i can try my best to help you.

3

arm-elf-gdb 6.8, openocd 0.1.0 (fedora fc10 rpm), libftd2xx.so.0.4.13, olimex arm-usb-ocd, LPC2119

Me too!

Debug: 325 33580 gdb_server.c:1369 gdb_step_continue_packet(): step
Debug: 326 33580 arm7_9_common.c:1966 arm7_9_read_memory(): address: 0x00000c72, size: 0x00000002, count: 0x00000001
Debug: 327 33606 target.c:1210 target_read_u16(): address: 0x00000c72, value: 0x2396
Segmentation fault

Doesn’t matter where you set the first breakpoint (ARM or THUMB), the first step causes a core dump.

There are too many other instabilities with openocd 0.1.0 (at least with my kit) so I’ve gone back to my old version (Sept. 07) which always works very reliably. (It’s a great shame; things like vflash is so stunningly fast but only worked once in 5 tries)

For what it’s worth: the above server crash possibly corresponds to what the old server flagged (incorrectly) as “arm7_9_common.c:1909 arm7_9_read_memory(): memory read caused data abort (address: 0xffffffff, size: 0x1, count: 0x4)”

4

hi onamatic,

what is your target board ?