无忧启动论坛

 找回密码
 注册
搜索
系统gho:最纯净好用系统下载站投放广告、加入VIP会员,请联系 微信:wuyouceo
查看: 5701|回复: 21
打印 上一主题 下一主题

最新版有 bug,请 chenall 留意

[复制链接]
跳转到指定楼层
1#
发表于 2014-9-11 19:07:38 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
2#
 楼主| 发表于 2014-9-13 08:01:57 | 只看该作者
8月19日也带来了 bug,请看 80 楼的最新报告:

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

回复

使用道具 举报

3#
发表于 2014-9-13 12:27:55 | 只看该作者
老外还真细心啊,好多bug还真是老外发现的。
回复

使用道具 举报

4#
发表于 2014-9-13 15:46:53 | 只看该作者
一直跟踪使用最新版本,比较容易发现问题.像第一个问题,只要有使用到fat命令就会发现问题了.

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

使用道具 举报

5#
 楼主| 发表于 2014-9-14 00:50:30 | 只看该作者
本帖最后由 不点 于 2014-9-14 01:08 编辑

  1. stage2/cmdline.c
  2. @@ -252,9 +252,14 @@ static int run_cmd_line (char *heap,int flags);
  3. int run_line (char *heap,int flags)
  4. {
  5. - char *arg = heap;
  6. + char *cmdline_buf = cmd_buffer;
  7. + char *arg;
  8. int status = 0;
  9. int ret = 0;
  10. + int arg_len = strlen(heap) + 1;
  11. + memmove(cmdline_buf,heap,arg_len);
  12. + cmd_buffer += arg_len;
  13. + heap = cmdline_buf;
  14. while(*heap && (arg = heap))
  15. {
  16. heap = skip_to_next_cmd(heap,&status,OPT_MULTI_CMD_AND | OPT_MULTI_CMD_OR | OPT_MULTI_CMD);//next cmd
  17. @@ -265,6 +270,7 @@ int run_line (char *heap,int flags)
  18. heap = skip_to_next_cmd(heap,&status,OPT_MULTI_CMD);//next cmd
  19. }
  20. }
  21. + cmd_buffer = cmdline_buf;
  22. return ret;
  23. }
复制代码


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

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



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

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

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

点评

我想我应该找到BUG原因了,不注意还真难发现.. + int arg_len = strlen(heap) + 1; + memmove(cmdline_buf,heap,arg_len); + cmd_buffer += arg_len; //这里至少再加1就行了,,唉,看来写代码还得注意再注意..  详情 回复 发表于 2014-9-15 14:58
昨天已经确认是这个改动引起的.. 这个改动主要是为了不改动用户的命令行. 比如在外部命令中执行了某一条命令,没改动之前,这个命令的内容会被改动(命令分隔). 我试试看增大缓存区,或者使用malloc预分配一块  详情 回复 发表于 2014-9-14 08:37
回复

使用道具 举报

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

可能 ...

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

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

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

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

使用道具 举报

7#
发表于 2014-9-14 10:47:26 | 只看该作者
楼上都是高淫...
回复

使用道具 举报

8#
发表于 2014-9-15 14:58:02 | 只看该作者
不点 发表于 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就行了,,唉,看来写代码还得注意再注意..

回复

使用道具 举报

9#
 楼主| 发表于 2014-9-15 15:25:32 | 只看该作者
第一行不是已经加过 1 了吗?再加 1 似乎是多余啊。

点评

这个cmd_buffer是一个暂存区,后面还会继续写入内容的.如果没有多留一个字节出来,那后面写入的内容就会接到字符'\0'处.造成字符串未截断.运行的命令就会出错.  详情 回复 发表于 2014-9-15 15:43
回复

使用道具 举报

10#
发表于 2014-9-15 15:43:42 | 只看该作者
不点 发表于 2014-9-15 15:25
第一行不是已经加过 1 了吗?再加 1 似乎是多余啊。

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

点评

第一行加的那个 1,本来就是计算这个结尾的 NULL 字符的。strlen 是不包括尾部的 NULL 的。再加 1 当然就已经包括 NULL 了。所以不会有问题。问题应该不在这里,而在其他地方。 heap 处,总的缓冲区空间不大,当  详情 回复 发表于 2014-9-15 16:30
回复

使用道具 举报

11#
 楼主| 发表于 2014-9-15 16:30:23 | 只看该作者
本帖最后由 不点 于 2014-9-15 16:37 编辑
chenall 发表于 2014-9-15 15:43
这个cmd_buffer是一个暂存区,后面还会继续写入内容的.如果没有多留一个字节出来,那后面写入的内容就会接 ...


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

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


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

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

点评

cmd_buffer 运行命令之前先把命令复制过去,并设置新的位置,运行完后恢复位置. 这个主要在run_cmd_line 和run_line这两个函数里面用到,都是在使用前记录一下当前位置,用完恢复. 运行完一整行命令之后,这个会恢  详情 回复 发表于 2014-9-15 16:55
嗯,想想也是,唉,乱了..也许是编译器优化的问题? 使用如下语句,试了一下好像没有问题了. cmd_buffer += (arg_len + 0xf) & ~0xf;  详情 回复 发表于 2014-9-15 16:49
回复

使用道具 举报

12#
发表于 2014-9-15 16:49:10 | 只看该作者
不点 发表于 2014-9-15 16:30
第一行加的那个 1,本来就是计算这个结尾的 NULL 字符的。strlen 是不包括尾部的 NULL 的。再加 1 当然 ...

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

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

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

点评

这还是无法解释2次+1的问题, 因为& ~0xf包含了+= arg_len + 0 的情况, 说明+0有时候可以通过. 如果cmd_buffer的内容是常量, 那大概还是内存覆盖了, 或者编译器优化错误(可能性不大吧)?  发表于 2014-9-19 19:14
回复

使用道具 举报

13#
发表于 2014-9-15 16:55:05 | 只看该作者
不点 发表于 2014-9-15 16:30
第一行加的那个 1,本来就是计算这个结尾的 NULL 字符的。strlen 是不包括尾部的 NULL 的。再加 1 当然 ...

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

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

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

使用道具 举报

14#
发表于 2014-9-20 14:15:51 | 只看该作者
@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;
回复

使用道具 举报

15#
发表于 2014-9-21 19:07:06 | 只看该作者
我报另一个莫名其妙的现象:2014-9-5的版本,显示中文会乱码,而此版本前及2014-9-8和2014-9-12版本无此现象(同一个菜单没有任何改动)。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1 )

闽公网安备 35020302032614号

GMT+8, 2024-11-30 12:31

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表