b***i 发帖数: 3043 | 1 嵌入式设备,一个CPU, 有网络芯片,有CF卡。用SanDisk api写CF,同时有一个tcp/
ip的库,似乎是poll,不是多任务的,没有os。
发现一个bug,有几个设备,CF卡里某个目录里面的文件消失了,原因是文件目录表被
最新的文件的内容,最后的一个扇区给覆盖了。比如文件最后一个扇区是字符串 5, 34
, time, 等,那么这些字符串就也出现在文件目录表那个cluster,该文件目录项所在
的扇区,比如如果是第33个文件,那么就不是文件目录表的第一个扇区。
这样的错误可能发生在什么地方?我看了,没发现网卡的中断执行过SanDisk api。当
然,我们的SanDisk api是没有critical section保护的,因为本来就不会重入。
大牛帮想想是什么原因?buffer overflow? stack overflow? 需要critical section
保护? |
F********g 发帖数: 475 | |
b***i 发帖数: 3043 | 3 是指api内部代码吗还是CF卡内部的嵌入式代码?
如果是api内部,写保护是什么意思?没有重入啊?
【在 F********g 的大作中提到】 : 写应该要保护的吧。 : 地址有算错吗?
|
n***e 发帖数: 723 | 4 什么文件系统?
【在 b***i 的大作中提到】 : 是指api内部代码吗还是CF卡内部的嵌入式代码? : 如果是api内部,写保护是什么意思?没有重入啊?
|
b***i 发帖数: 3043 | 5 FAT16
【在 n***e 的大作中提到】 : 什么文件系统?
|
b***i 发帖数: 3043 | 6 找到问题原因了,哈哈哈哈
庆祝一个星期吃龙虾了
34
section
【在 b***i 的大作中提到】 : 嵌入式设备,一个CPU, 有网络芯片,有CF卡。用SanDisk api写CF,同时有一个tcp/ : ip的库,似乎是poll,不是多任务的,没有os。 : 发现一个bug,有几个设备,CF卡里某个目录里面的文件消失了,原因是文件目录表被 : 最新的文件的内容,最后的一个扇区给覆盖了。比如文件最后一个扇区是字符串 5, 34 : , time, 等,那么这些字符串就也出现在文件目录表那个cluster,该文件目录项所在 : 的扇区,比如如果是第33个文件,那么就不是文件目录表的第一个扇区。 : 这样的错误可能发生在什么地方?我看了,没发现网卡的中断执行过SanDisk api。当 : 然,我们的SanDisk api是没有critical section保护的,因为本来就不会重入。 : 大牛帮想想是什么原因?buffer overflow? stack overflow? 需要critical section : 保护?
|
n***e 发帖数: 723 | 7 呵呵,恭喜恭喜!
给说说原因?
我猜是不不是哪个index溢出了?
【在 b***i 的大作中提到】 : 找到问题原因了,哈哈哈哈 : 庆祝一个星期吃龙虾了 : : 34 : section
|
b***i 发帖数: 3043 | 8 不完全是。答案对了一半。再猜?
【在 n***e 的大作中提到】 : 呵呵,恭喜恭喜! : 给说说原因? : 我猜是不不是哪个index溢出了?
|
n***e 发帖数: 723 | 9 猜不出。。。求答案!
【在 b***i 的大作中提到】 : 不完全是。答案对了一半。再猜?
|
b***i 发帖数: 3043 | 10 是一个 计数器,用来记毫秒数的溢出,大概2^32毫秒就溢出(每1毫秒加一次),就是
大约50天。而我们两个设备都是在50天左右出现了错误的文件目录区。就是SanDisk的
API没有考虑这个问题,它们的代码在等待的时候是直接比较当前的毫秒计数和预期计
数,而不是先做减法再跟等待的毫秒数比较。快溢出的的时候如果正好马上等待,那么
等待不会进行。
【在 n***e 的大作中提到】 : 猜不出。。。求答案!
|
n***e 发帖数: 723 | 11 这个您都能找出来!拜服中!
【在 b***i 的大作中提到】 : 是一个 计数器,用来记毫秒数的溢出,大概2^32毫秒就溢出(每1毫秒加一次),就是 : 大约50天。而我们两个设备都是在50天左右出现了错误的文件目录区。就是SanDisk的 : API没有考虑这个问题,它们的代码在等待的时候是直接比较当前的毫秒计数和预期计 : 数,而不是先做减法再跟等待的毫秒数比较。快溢出的的时候如果正好马上等待,那么 : 等待不会进行。
|
b***i 发帖数: 3043 | 12 准确的死机时间是49.7天。结果一个学机械的经理上网一看,
Windows 98
【在 n***e 的大作中提到】 : 这个您都能找出来!拜服中!
|