码迷,mamicode.com
首页 > 系统相关 > 详细

Linux Debugging(八): core真的那么难以追踪吗?

时间:2014-10-24 00:28:39      阅读:255      评论:0      收藏:0      [点我收藏+]

标签:linux debugging   调试   core分析   dump分析   线程变量   

本周遇到了好几个core都很有典型性。在这里和大家分享下。

相信有过Linux编程经验的人,肯定都遇到过。感觉周围人很多对core有天然的恐惧感,尤其对刚入行不久的同学来说。当然了,也有工作好几年看到core也束手无策的。今天就分析一下,core,其实大部分都是很容易解决的。如果一个core很难以复现,那么说明还是很复杂的,算是Corner case,可能需要很长时间,脑子里要有很好的运行时状态才可以(阅读源码,学习的是逻辑;将源码对应到运行时的状态,分析一些状态机的转换,再去分析可能会发生的情况)。相信前几篇文章会对这种Corner case的分析与解决打下比较好的基础。

相反,那种每次必现,或者复现比率非常高的case,是非常容易解决的。


多线程必然出core?

如果是你新加入的代码引入的core,实际上非常容易解决的,简单的对比一下修改的diff,然后看一下是否有比较低级的错误。如果发现不了,看是否是多线程的问题?单线程如果没有出core,改成多线程就出core,那么就说明多线程竞争某些变量了:同时修改某些变量导致出问题。这个时候你可能第一反应会加锁。我本人非常反感加锁;即使你加锁的粒度很小,作用域也够小,但是只要是加锁,就代表有阻塞,就代表维护起来会很麻烦。这些共享变量真的那么值得加锁吗?可否换成局部变量?如果他是一块动态内存,为了调用某个接口时不要频繁申请释放内存(比如这个接口每秒几千次的调用),那么初始化时候申请一块内存是绝对合理的:请把它设置为线程变量吧。每个线程初始化时候申请这块内存。

当然了你如果实现的是一个框架或者架构调用的接口,这个接口要做到线程安全的。那么看起来你并不能控制这个线程什么时候启动;线程数目会是多少个,那么就没有办法了吗?

实际上,方法有很多,比如,你可以在一个map中维护一个“线程”变量的对应关系

__gnu_cxx::hash_map< pid_t, void *> thread_data_map;
void * thread_buffer;
std::map<pid_t, void *>::iterator it;
lock
it = thread_data_map.find(pid);
if (it == thread_data_map.end()) {
    //init "thread data"
    thread_data_map[pid] = create_buffer();
} else {
    thread_buffer = it->second;
}
unlock


这里不得不使用了一个锁。实际上由于线程数是有限的,因此这个效率还好。我本周实现了一个qps可以达到2000+的在线应用,基本上锁的代价在整个的call stack中可以忽略不计。

当然了,比较好的框架可能会提供OnThreadInit这种接口,那么在这边申请线程变量吧:

int pthread_setspecific (pthread_key_t key, const void *value);

在实现逻辑的函数获取该变量即可:

void *pthread_getspecific (pthread_key_t key);

什么时候要使用线程变量?看多线程下是否对该变量有写操作,如果有就要申请线程变量(或者加锁),否则必然出core。


不要给自己埋下一个坑:


今天一个同学的core看起来是做了一个“优化”,节省了申请变量的时间。

void init() {
    my_struct * some_var;
    ...
    some_var->res = new some_res;
    some_var->res->set_value1(some_common_value1);
    some_var->res->set_value2(some_common_value2);
}

void * thread_func(my_struct * some_var) {
     
    some_var->res->set_value3(value_3);
   ...
}

set_value3就是一个出core的原因。这个也是一个典型的多线程必然出core的case。实际上,res没必要提前申请吧。把它改成一个局部变量,性能几乎没有的损耗。当然了,如果这个资源很大,那么就当成线程变量吧。


那么如何分析core?

实际上,上述的场景出现的core如果仅从core本身,可能一时不好排查问题出在哪里;而且core的位置可能还不一样,不可避免的出现替罪羊;比如调用第三方的模块,实际上是自己的全局变量导致到了第三方的调用栈时出core了。因此一定要排查自己的处理是否正确。

确定调用的接口是否线程安全;如果是你的同事,你得确定他说的是对的。就像今天又另外的一个core,调用者坚称他写的是线程安全的,仿佛不是线程安全的就像是代码写的不好似得;最后排查出他写的代码不是线程安全时,他问你什么是线程安全的。

那么回答一下,如何分析core?

首先了解清楚core出现的应用场景,比如长句子处理会有core;多线程处理会有core;特殊字符会有core;这个QA会给你一个比较清楚的说明。然后通过core的call stack去大概确定大概的源码位置。

源码面前,了无秘密。

你读源码,它展现的是逻辑;但是你脑中,要有个runtime的运行时调用栈,多线程的调度;天马行空。

当然了,还是解决不了,开始从core得到更详细的信息吧!看看调用栈的参数是什么,切换一个线程看看其他的几个线程的frame是什么。

还解决不了?

那么它是Corner case,只要把应用在core后立即启动就行了。记得EMC有个bug的选项是unable to root cause, 形容的很贴切。同时不要忘记自我安慰:码的码多了,肯定有bug,谁能保证服务100%呢?


Linux Debugging(八): core真的那么难以追踪吗?

标签:linux debugging   调试   core分析   dump分析   线程变量   

原文地址:http://blog.csdn.net/anzhsoft/article/details/40405413

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!