背景
我正在编写一个工具来通过USB启动嵌入式ARM系统。这个特定的ARM系统具有一个引导加载程序，该引导加载程序可以通过模拟大容量存储设备并实施一些供应商SCSI操作码来通过USB加载系统，从而使主机可以将信息写入内存。我的工具在嵌入式ARM系统所连接的主机上运行，它是使用这些供应商命令将zImage或其他二进制文件发送到设备的。
我使用Linux通用SCSI接口发送命令。
发送一些命令以将值写入控制RAM控制器的寄存器后，我的程序打开一个文件，然后进入一个循环，在该循环中，该循环一次从文件中读取4096字节，然后将其发送到设备。
我没有需要发送的SCSI命令的任何文档。我已经通过捕获和分析由供应商提供的等效的仅Windows工具发送的USB流量来确定要使用的协议。该协议有一些奇怪的方面，特别是它接受小端格式的地址和值，并且SCSI命令中的32位值不是字对齐的，但是我认为这些与当前的问题无关。
问题
发送前7个缓冲区后，程序将进行段错误处理。
segfaults的部分如下：
int ak_usbboot_writefile(ak_usbboot_dev* dev, const char *filename, uint32_t addr) {
uint8_t dataBuff[DATABUFF_SIZE];
size_t len;
printf("STOREFILE: FILENAME=%s ADDR=%08x\n", filename, addr);
ak_usbboot_errno = AK_USBBOOT_OK;
FILE *f = fopen(filename, "rb");
if (f==NULL) {
ak_usbboot_errno = errno;
return errno;
}
/* Segfault occurs on the next line */
while ( (len = fread(dataBuff, 1, DATABUFF_SIZE, f)) > 0) {
printf("read len=%ld\n", len);
int r = ak_usbboot_storemem(dev, dataBuff, len, addr);
if (r!=AK_USBBOOT_OK) {
goto EXIT;
}
addr += len;
}
节段发生调用fread。回溯看起来像这样：
#0 __memcpy_sse2 () at ../sysdeps/x86_64/memcpy.S:272
#1 0x00007f92907b9233 in __GI__IO_file_xsgetn (fp=0x1f10030, data=<optimized out>, n=4096) at fileops.c:1427
#2 0x00007f92907ae9d8 in __GI__IO_fread (buf=<optimized out>, size=1, count=4096, fp=0x1f10030) at iofread.c:42
#3 0x0000000000401492 in ak_usbboot_writefile (dev=0x1f10010, filename=0x7fff078b0718 "/home/harmic/git/Lamobo-D1s/tool/burntool/zImage", addr=2174808064) at ak_usbboot.c:217
#4 0x0000000000400c4d in ak_boot (dev_name=0x7fff078b070f "/dev/sg2", file=0x7fff078b0718 "/home/harmic/git/Lamobo-D1s/tool/burntool/zImage") at main.c:86
#5 0x0000000000400d68 in cmd_boot (argc=2, argv=0x7fff078af538) at main.c:114
#6 0x0000000000400dfc in main (argc=4, argv=0x7fff078af528) at main.c:130
我看不到文件处理方式有任何问题，如果我注释掉对ak_usbboot_storemem的调用，则循环将毫无问题地完成。
ak_usbboot_storemem看起来像这样：
int ak_usbboot_storemem(ak_usbboot_dev* dev, const void* buffer, uint32_t len, uint32_t addr) {
uint8_t cmdBuff[16] = {
0xf1, 0x3f, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x68, 0, 0
};
printf("STORE: INBUFF=%p LEN=%08x ADDR=%08x\n", buffer, len, addr);
memcpy(&cmdBuff[5], &addr, 4);
memcpy(&cmdBuff[9], &len, 4);
return _sendCmd(dev, &cmdBuff, sizeof(cmdBuff), (void*)buffer, len, SG_DXFER_TO_DEV);
}
_sendCmd看起来像这样：
int _sendCmd(ak_usbboot_dev* dev, const void* cmdBuff, int cmdLen, void* dataBuff, int dataLen, int sg_dir) {
fputs("CMD: ", stdout);
const uint8_t* p = (const uint8_t*)cmdBuff;
for (int i=0; i<cmdLen; i++) {
printf("%02x ", *p++);
}
fputs("\n", stdout);
sg_io_hdr_t io_hdr = {
.interface_id = 'S',
.dxfer_direction = sg_dir,
.cmd_len = cmdLen,
.mx_sb_len = sizeof(dev->sense_buffer),
.iovec_count = 0,
.dxfer_len = dataLen,
.dxferp = dataBuff,
.cmdp = (void*)cmdBuff,
.sbp = dev->sense_buffer,
.timeout = 10000,
.flags = 0,
.pack_id = 0,
};
if (ioctl(dev->fd, SG_IO, &io_hdr) < 0) {
ak_usbboot_errno = errno;
return ak_usbboot_errno;
}
if ((io_hdr.info & SG_INFO_OK_MASK) != SG_INFO_OK) {
dev->sb_len = io_hdr.sb_len_wr;
dev->driver_status = io_hdr.driver_status;
dev->masked_status = io_hdr.masked_status;
dev->host_status = io_hdr.host_status;
ak_usbboot_errno = AK_USBBOOT_SCSIERR;
return AK_USBBOOT_SCSIERR;
} else {
dev->err = AK_USBBOOT_OK;
return AK_USBBOOT_OK;
}
}
我猜我正在使用SCSI通用IOCTL做某事，但是到目前为止我还无法发现任何东西。
欢迎任何见识！
最佳答案
@Andrew Medico的评论使我走上了正确的道路。我应该早些考虑使用valgrind。
Valgrind报告了多个错误，如下所示：
==28114== Invalid write of size 4
==28114== at 0x400FF5: _sendCmd (ak_usbboot.c:73)
==28114== by 0x4010D7: ak_usbboot_open (ak_usbboot.c:104)
==28114== by 0x400B7E: ak_boot (main.c:70)
==28114== by 0x400D67: cmd_boot (main.c:114)
==28114== by 0x400DFB: main (main.c:130)
==28114== Address 0x51f3074 is not stack'd, malloc'd or (recently) free'd
在valgrind下运行时，程序正常完成，可以正常启动设备！
ak_usbboot.c：73是这一行：
dev->err = AK_USBBOOT_OK;
这使我更加仔细地研究了dev的分配位置：
ak_usbboot_dev* dev = malloc(sizeof(dev));
哎呀我正在为指针（而不是指针）分配足够的空间。结果，写入结构破坏了堆。
当然应该是：
ak_usbboot_dev* dev = malloc(sizeof(*dev));
这个答案可能对其他任何人都没有多大用处，只是作为有关如何查找此类问题的提示-valgrind是天赐之物。
关于c - 通用scsi ioctl之后的读取期间出现段错误，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/28962444/