无忧启动论坛

标题: 最新版有 bug，请 chenall 留意 [打印本页]

作者: 不点 时间: 2014-9-11 19:07
标题: 最新版有 bug，请 chenall 留意
见英文论坛 steve 的报告:

http://reboot.pro/topic/20000-boot-windows-iso-without-bootfixbin-press-any-key-prompt/page-4

作者: 不点 时间: 2014-9-13 08:01
8月19日也带来了 bug，请看 80 楼的最新报告：

http://reboot.pro/topic/20000-boot-windows-iso-without-bootfixbin-press-any-key-prompt/page-4

作者: zhaohj 时间: 2014-9-13 12:27
老外还真细心啊，好多bug还真是老外发现的。

作者: chenall 时间: 2014-9-13 15:46
一直跟踪使用最新版本,比较容易发现问题.像第一个问题,只要有使用到fat命令就会发现问题了.

8月19的问题我还没有找到原因,暂时没有从代码上看出什么毛病来.,需要找时间测试下.

作者: 不点 时间: 2014-9-14 00:50
本帖最后由不点于 2014-9-14 01:08 编辑

stage2/cmdline.c
@@ -252,9 +252,14 @@ static int run_cmd_line (char *heap,int flags);
int run_line (char *heap,int flags)
{
- char *arg = heap;
+ char *cmdline_buf = cmd_buffer;
+ char *arg;
int status = 0;
int ret = 0;
+ int arg_len = strlen(heap) + 1;
+ memmove(cmdline_buf,heap,arg_len);
+ cmd_buffer += arg_len;
+ heap = cmdline_buf;
while(*heap && (arg = heap))
{
heap = skip_to_next_cmd(heap,&status,OPT_MULTI_CMD_AND | OPT_MULTI_CMD_OR | OPT_MULTI_CMD);//next cmd
@@ -265,6 +270,7 @@ int run_line (char *heap,int flags)
heap = skip_to_next_cmd(heap,&status,OPT_MULTI_CMD);//next cmd
}
}
+ cmd_buffer = cmdline_buf;
return ret;
}

复制代码

我粗略看了一下，8月19日的改动不多，其他改动都不会有问题，唯独上面这个改动有可能出问题。

可能是内存产生了冲突或溢出。内存溢出的错误通常都很隐蔽的，不容易排查。

改动之前 heap 的值保持不变，但改动之后，heap 的值更新了。

另外，使用了 memmove 进行内存复制。会不会 heap 和 cmd_buffer 都指向同一个内存缓冲区，距离太近，导致互相覆盖？

我没看明白为何要改动 cmdline.c 里面的 run_line 函数。更新记录里面没有相关的记录。是排解 bug 吗？是增强什么功能吗？这个改动究竟是什么意思？

作者: chenall 时间: 2014-9-14 08:37

不点发表于 2014-9-14 00:50
我粗略看了一下，8月19日的改动不多，其他改动都不会有问题，唯独上面这个改动有可能出问题。

可能 ...

昨天已经确认是这个改动引起的..

这个改动主要是为了不改动用户的命令行.

比如在外部命令中执行了某一条命令,没改动之前,这个命令的内容会被改动(命令分隔).

我试试看增大缓存区,或者使用malloc预分配一块内存看看能否解决.

作者: 邪恶海盗 时间: 2014-9-14 10:47
楼上都是高淫...

作者: chenall 时间: 2014-9-15 14:58

不点发表于 2014-9-14 00:50
我粗略看了一下，8月19日的改动不多，其他改动都不会有问题，唯独上面这个改动有可能出问题。

可能 ...

我想我应该找到BUG原因了,不注意还真难发现..

+ int arg_len = strlen(heap) + 1;
+ memmove(cmdline_buf,heap,arg_len);
+ cmd_buffer += arg_len; //这里至少再加1就行了,,唉,看来写代码还得注意再注意..

作者: 不点 时间: 2014-9-15 15:25
第一行不是已经加过 1 了吗？再加 1 似乎是多余啊。

作者: chenall 时间: 2014-9-15 15:43

不点发表于 2014-9-15 15:25
第一行不是已经加过 1 了吗？再加 1 似乎是多余啊。

这个cmd_buffer是一个暂存区,后面还会继续写入内容的.如果没有多留一个字节出来,那后面写入的内容就会接到字符'\0'处.造成字符串未截断.运行的命令就会出错.

作者: 不点 时间: 2014-9-15 16:30
本帖最后由不点于 2014-9-15 16:37 编辑

chenall 发表于 2014-9-15 15:43
这个cmd_buffer是一个暂存区,后面还会继续写入内容的.如果没有多留一个字节出来,那后面写入的内容就会接 ...

第一行加的那个 1，本来就是计算这个结尾的 NULL 字符的。strlen 是不包括尾部的 NULL 的。再加 1 当然就已经包括 NULL 了。所以不会有问题。问题应该不在这里，而在其他地方。

heap 处，总的缓冲区空间不大，当你把它截为两个（或多个）短的空间段之后，可能不够用了，或者互相覆盖了，这可能是导致问题的根源。

另外。cmd_buffer 不是个局部变量，未打补丁之前，它是未被修改的，而你的补丁却修改了它。

试想，如果 cmd_buffer 的值不断被修改和增长，那它迟早要超过它的缓冲区上限，导致内存其他数据的损毁。

作者: chenall 时间: 2014-9-15 16:49

不点发表于 2014-9-15 16:30
第一行加的那个 1，本来就是计算这个结尾的 NULL 字符的。strlen 是不包括尾部的 NULL 的。再加 1 当然 ...

嗯,想想也是,唉,乱了..也许是编译器优化的问题?

使用如下语句,试了一下好像没有问题了.

cmd_buffer += (arg_len + 0xf) & ~0xf;

作者: chenall 时间: 2014-9-15 16:55

不点发表于 2014-9-15 16:30
第一行加的那个 1，本来就是计算这个结尾的 NULL 字符的。strlen 是不包括尾部的 NULL 的。再加 1 当然 ...

cmd_buffer 运行命令之前先把命令复制过去,并设置新的位置,运行完后恢复位置.

这个主要在run_cmd_line 和run_line这两个函数里面用到,都是在使用前记录一下当前位置,用完恢复.

运行完一整行命令之后,这个会恢复为原始的值.

作者: chenall 时间: 2014-9-20 14:15
@2013gdh

从我目前所了解的知识来看,应该是编译器优化出错了.

因为我通过编译过的汇编代码对比发现,出现问题的汇编代码里面没有对应的+1的汇编代码.
int arg_len = strlen(heap) + 1;
cmd_buffer +=arg_len;

而当我把cmd_buffer这一句改成如下时,可以看到汇编代码里面有一个inc指令.
cmd_buffer += (arg_len + 0xf) & ~0xf;

当然我有考虑到您所说的+0的情况,所以现在的版本里面的代码是如下的,保证16个字节对齐.看起来没有问题.
cmd_buffer += (arg_len + 0x10) & -0x10;

作者: xianglang 时间: 2014-9-21 19:07
我报另一个莫名其妙的现象：2014-9-5的版本，显示中文会乱码，而此版本前及2014-9-8和2014-9-12版本无此现象（同一个菜单没有任何改动）。

欢迎光临无忧启动论坛 (http://wuyou.net./)