专栏首页方亮bug诞生记——临时变量、栈变量导致的双杀

bug诞生记——临时变量、栈变量导致的双杀

        这是《bug诞生记》的第一篇文章。本来想起个文艺点的名字,比如《Satan(撒旦)来了》,但是最后还是想让这系列的重心放在“bug的产生过程”和“缺失的知识点”上,于是就有了本系列这个稍微中性的名称。(转载请指明出于breaksoftware的csdn博客)

        本系列博文的案例将都秉承一个原则——“因知识缺失,而非粗心大意导致”。在实际工作中,粗心大意产生的bug太多了。但这是工作态度或者工作状态导致的,要去解决这个问题,可能会从机制、管理等角度来讲述。但是这不是本系列想讨论的。本系列更想讲述的是一种“无心之过”,即因为相应知识点的缺乏,程序员想当然的做法导致的bug。

        这篇我将讲述一个真实发生在工作中的例子。当然实际的代码和逻辑远比下文例子要复杂很多,我只是抽出比较核心的点来分析。至于为什么要这么做?为什么要这么设计?为什么要这种风格?为什么代码不严谨?……等与问题核心无关的疑问,我都将不做辩论。这个“免责声明”也将贯穿本系列所有例子。

       下面这段代码用于拼装出一个绝对路径

std::string get_name(const std::string& index) {
	char name[16] = "Movie";
	std::string full_name = std::string(name) + index;
	return full_name;
}

int main() {
	char full_path[32] = "/home/work/";
	std::string name = get_name("1");
	const char* ptr_name = name.c_str();
	strcat(full_path + strlen(full_path), ptr_name);
	printf(full_path);
	return 0;
}

        它将输出/home/work/Movie1。

        目前它还没什么问题,后来发生的逻辑变更:只要返回固定的/home/work/Movie路径就行了。于是程序员的改法是

std::string get_name(/*const std::string& index*/) {
	char name[16] = "Movie";
	std::string full_name = std::string(name);// + index;
	return full_name;
}

int main() {
	char full_path[32] = "/home/work/";
	std::string name = get_name(/*"1"*/);
	const char* ptr_name = name.c_str();
	strcat(full_path + strlen(full_path), ptr_name);
	printf(full_path);
	return 0;
}

        程序员将之前的代码注释掉了,当然这个行为是非常不好的。

        此时一个具有“良知”但是“缺乏知识点”的同事将走上“犯罪”的道路,因为他将抱着“优化代码”的目的去产生了第一个bug。他是这么改的

std::string get_name() {
	char name[16] = "Movie";
	return std::string(name);
}

int main() {
	char full_path[32] = "/home/work/";
	const char* ptr_name = get_name().c_str();
	strcat(full_path + strlen(full_path), ptr_name);
	printf(full_path);
	return 0;
}
  1. 把注释掉的废弃代码给删掉了。这是值得肯定的。
  2. 精简了get_name函数,不再以full_name作为返回值,减少了一次std::string类型的构造和释放。这个也是值得肯定的。
  3. 精简了main函数,删除了std::string name局部变量,试图直接从get_name()获取const char*指针。他的想法是好的,但是这步将导致bug。

        这段代码没有经过测试就上线了。因为他和QA都觉得这点小的改动不需要测试。很可惜,自以为是往往要付出代价。因为这段代码的最终执行结果是/home/work,而不是约定的/home/work/Movie。那Movie去哪里了?

        问题就出在第8行代码。一般情况下我们认为它可以翻译为下面两行

std::string temp = get_name();
const char* ptr_name = temp.c_str();

        如果的确是上面这么翻译的,那也没问题。但是实际上,temp是个行内的临时变量,它脱离了该行就被释放了。我们看下反汇编

	const char* ptr_name = get_name().c_str();
 lea         eax,[ebp-148h]  
 push        eax  
 call        get_name (0851672h)  
 add         esp,4  
 mov         dword ptr [ebp-15Ch],eax  
 mov         ecx,dword ptr [ebp-15Ch]  
 call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::c_str (085166Dh)  
 mov         dword ptr [ptr_name],eax  
 lea         ecx,[ebp-148h]  
 call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> > (08513D9h)  

        第4行调用了get_name方法,返回的std::string对象指针放在eax中。

        第6行将该对象指针放到当前函数栈帧内——即一个临时对象。

        第7行又将临时对象地址放到ecx中。ecx在C++编译中,一般用于传递this指针。

        第8行对ecx中保存的std::string临时对象的this指针调用了c_str成员方法,得到的const char*地址保存在eax中。

        第9行将上一指令返回的const char*地址保存到ptr_name局部变量中,此时ptr_name指向的是std::string临时对象的字符空间地址。它也就在这一刻是该程序员所期望的样子。

        第10行和第11行,又通过ecx调用std::string的析构函数。这样保存在[ebp-148h]中的std::string对象指针指向的临时对象被析构,也就意味着第9步得到的指针数据被删除了。

        所以const char* ptr_name = get_name().c_str();正确的翻译是

const char* ptr_name = NULL;
{
	std::string temp = get_name();
	ptr_name = temp.c_str();
}

        最终这个程序员老老实实的把main中那行“精简代码”变成了两行

std::string get_name() {
	char name[16] = "Movie";
	return std::string(name);
}

int main() {
	char full_path[32] = "/home/work/";	
	std::string name = get_name();
	const char* ptr_name = name.c_str();
	strcat(full_path + strlen(full_path), ptr_name);
	printf(full_path);
	return 0;
}

        我想经过这次惊魂实践,这个程序员应该再也不想碰这块代码了。

        但是肯定还有其他“有良知”的程序员,他会觉得这代码很不爽——搞什么std::string?转来转去,最终还是用了const char*。

        于是他修改如下

const char* get_name() {
	char name[16] = "Movie";
	return name;
}

int main() {
	char full_path[32] = "/home/work/";	
	const char* ptr_name = get_name();
	strcat(full_path + strlen(full_path), ptr_name);
	printf(full_path);
	return 0;
}
  1. 将get_name方法的返回类型改成了const char*,省去了中间std::string的转换。
  2. 将main中的std::string全干掉了。

        这段代码修改的足够简单了。有人可能会觉得get_name可能可以干掉,直接在main函数中写死路径就行了。我想当时这个程序员保留get_name的原因可能是他预测该函数可能还是存在被定制的可能性。

        抛开其他问题,这段程序的执行结果是正确的。相信这个版本的修改者此时内心是澎湃的,因为他觉得他不费吹灰之力,就干了一件好事。可是实际他却挖了一个坑。

        这段代码在线上稳定运行了很久,后来随着业务逻辑的增长。一个同学不小心在第8和第9行代码之间插入了一个函数调用,然后这个程序就崩掉了。相信这个同学一定很郁闷,因为他可能仅仅修改了一下函数调用顺序,或者写了一个足够简单到不太可能出错的代码。结果进程崩溃,他要背锅!

        为了把问题简单化,我让新插入的代码只干一件事——初始化一个栈上空间。

const char* get_name() {
	char name[16] = "Movie";
	return name;
}

void satan() {
	char name[16] = "I am Satan";
}

int main() {
	char full_path[32] = "/home/work/";	
	const char* ptr_name = get_name();
	satan();
	strcat(full_path + strlen(full_path), ptr_name);
	printf(full_path);
	return 0;
}

        这个程序的输出是/home/work/I am Satan。仅仅加了一个satan函数,就改变了结果?是的。这是由于之前那个做代码修改的同学对栈变量和栈帧不熟悉导致的。

        如果要介绍栈变量和栈帧,这个就需要从计算机基础知识讲起。本文当然不会讲的很细,大家可以通过其他渠道获取这些知识。

        下面的图只是表意,不是准确表达栈空间清空。但是核心的意思是一致的。

        进入main函数时,栈结构如下

        红色表示当前活动的栈空间;绿色表示“未知区域”,该区域的数据我们可以认为是“野”的,不可保障的。

        进入get_name函数后,栈结构变化如下

        get_name的name数组将保存“Movie”。

        get_name调用结束,发生退栈行为。于是程序又回到main函数中,其栈结构如下

        注意一下,第12行代码已经让ptr_name指向了“野”空间。此时“野”空间数据还没被污染,所以执行结果还是正确的。

        然后我们调用了satan函数。进入satan函数后栈结构如下

        注意一下,之前get_name的name空间已经被satan的name空间覆盖了。此时它的数据是“I am Satan”。

        satan函数结束后,又回到main函数空间,其栈结构如下

        我们看到,此时ptr_name还是指向“野”空间。只是此时空间不再是调用get_name时的情况,栈上数据已经被satan函数“污染”了。

        所以出现错误的结果是必然的。

        这段不到15行的代码经过多个程序员的修改后,仿佛成了一个江湖。其中发生了各种因为“知识点缺乏”而导致的bug。所以如果我们不知道代码最终精确的表达,可能就会写出各种“不经意”的问题。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 从0开始搭建编程框架——主框架和源码

    一个良好的结构是“对修改关闭,对扩展开放”的。(转载请指明出于breaksoftware的csdn博客)

    方亮
  • 从0开始搭建编程框架——主框架和源码

            一个良好的结构是“对修改关闭,对扩展开放”的。(转载请指明出于breaksoftware的csdn博客)

    方亮
  • bug诞生记——const_cast引发只读数据区域写违例

            对于C++这种强类型的语言,明确的类型既带来了执行的高效,又让错误的发生提前到编译期。所以像const这类体现设计者意图的关键字,可以隐性的透露...

    方亮
  • python中的内置函数(双下划线) 原

    如果我们是直接执行某个.py文件的时候,该文件中那么”__name__ == '__main__'“是True,但是我们如果从另外一个.py文件通过import...

    晓歌
  • RabbitMq的消息队列类型direct、fanout、topic、headers(headers抛弃)

    1 服务端 server 将 消息 msg_txt 投递 到 交换器 exchange_name 路由键为 routing_key_name ,当 有队列 qu...

    93年的老男孩
  • Python+Selenium 技巧篇-svg标签内元素的xpath定位方式

    这种元素比较特殊,需要通过 name 属性来进行定位。 写法如下: //*[name()="svg"]//*[name()="image"]

    小蓝枣
  • tekton入门-trigger

    trigger使用户能够将事件有效负载中的字段映射到资源模板中。换句话说,这允许事件既可以建模也可以将实例化为Kubernetes资源。对于tektoncd/p...

    有点技术
  • Android的Wifi连接

    最近在做Wifi连接的功能,在网上查找了很多资料,可用的也比较少,最后遇到很多了问题,一路走来也解决了很多问题,特此记录。

    None_Ling
  • Python Redis

      NoSQL(NoSQL = Not Only SQL ),意即“不仅仅是SQL”,是一项全新的数据库革命性运动,泛指非关系型的数据库。随着互联网web2.0...

    py3study
  • 为什么要关注索引统计误差

    事情的起因是,我的朋友小明同学有一天突然发现有个SQL的执行计划出问题了。经过一番排查,居然发现是该表的辅助索引统计信息存在严重偏差。

    [3306 Pai ] 社区

扫码关注云+社区

领取腾讯云代金券