On Mon, 18 May 2009, Peter Denison wrote:

> Now, on to the actual crash. I will do more investigation, but for now, 
> here's the backtrace:
>
> Starting program: <path>/src/.libs/lt-openocd -f 
> ../../../openocd-usr8200-jlink.cfg
> Open On-Chip Debugger 0.2.0-in-development (2009-05-18-18:52) svn:1827M
>
> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
>
> $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
> jtag_speed: 16
> Error: J-Link command EMU_CMD_VERSION failed (-110)
>
> Error: J-Link command EMU_CMD_VERSION failed (-110)
>
>
> Program received signal SIGSEGV, Segmentation fault.
> jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940
> 940           result = usb_bulk_write_ex(jlink_jtag->usb_handle, 
> JLINK_WRITE_ENDPOINT,
> (gdb) bt
> #0  jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940
> #1  0xb7feaaf8 in jlink_simple_command (command=1 '\001') at jlink.c:509
> #2  0xb7febbb0 in jlink_get_version_info () at jlink.c:549
> #3  0xb7febf2d in jlink_init () at jlink.c:324
> #4  0xb7fe2bbf in jtag_interface_init (cmd_ctx=0x804a008) at jtag.c:2333

Preliminary look at this seems to be that jlink_jtag_handle is overwritten 
with junk. This sits in memory directly after usb_emu_result_buffer, which 
is 64 bytes long. Are any of the new in_handler replacement callbacks 
overwriting the end of this buffer?
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to