On Mon, 18 May 2009, Peter Denison wrote: > 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?
Sorry - that was a wild guess, and was totally wrong. It seems that the interface (I have the yellow J-Link V6) can get into an odd state where it responds incorrectly to an EMU_CMD_VERSION command (0x01). In this state, it replies with the string "J-Link ARM V6 compiled Mar 3 2008 18:04:42" immediately, without sending the 0x0070 length field first. I have confirmed this with the kernel-level USB trace provided by usbmon. The result is that the first two characters get interpreted as a length, "J-" = 0x4a 0x2d => 0x2d4a = 11594, much larger than the 2048 bytes allocated for the USB input buffer. With the changes introduced in r1475, where the expected length is passed to the bulk read function, this will now time out and/or overwrite usb_read_buffer. In jlink_usb_read() we should definitely check that the expected size is not larger than the buffer. That will catch the segfault. What the correct course of action after that is, I don't know. Put in an explicit check for length == 0x2d4a, and emit a message suggesting an adapter power-cycle? I'm open to suggestions. I'll see if I can produce a workable patch... _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
