|
锁定老帖子 主题：你必须解决它
精华帖 (0) :: 良好帖 (11) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-10-26
我很想感受一下这种压力！
callofseen 写道 tuti 写道 2008lilewei 写道 callofseen 写道 抛出异常的爱 写道 callofseen 写道 从上周5开始。4天了。也是并发造成的死锁。没有panic，没有core，没有log。但是机器就是一遍又一遍的重启。每天都是2点之后睡觉。昨天咳嗽了一晚上，没睡觉。我有点绝望了。
dump log 有没有 木有任何log。这里的运行环境比kernel还底层。log是靠UDP stack发送到syslog的。一旦CPU锁死了，任何信息都发不出来了。只有serial console寥寥几句无用的话。 这种情况确实让人抓狂，我最近也遇到了类似的问题，也是N久没有找出来问题所在，内心都有阴影了。但就像LZ所说的，你必须解决他 ！ 兄弟，要顶住 ！ 可以找人结对一下,一个人的思维有局限性,而且自己还意识不到. 当你能把问题清晰得向另一个人描述出来时,往往会有意想不到的效果. 嗯。。。开始状态十分低迷，没想到这么多热心相助的同学，现在精神好了不少。 涉及的代码不多，大概2000行。而且每个字都是我自己敲出来的。加上这几天每天熬夜，基本上每行代码连同缩进和注释我都能背出来了。 其实难的不在于这个问题能不能解决。难点在于这个周末就要交货给客户了。这客户不是好惹的主，一旦delay，就是赔偿几百万USD。这当口出了错，压力太大了。 现在我基本放弃修修补补的A计划，打算改plan B了。放弃这2000行代码。写个性能差些但是确保稳定的顶_上去。然后在下次deliver之前再回头来修改A。 一晚上写了几封信给其他同事。等他们上班了，最后确定一下plan B，然后开工赶代码和测试。想想很可笑，无奈的笑。2个月前写的东西，在deadline最后2天被推翻重写。这个时候信心比什么都重要。 我工作差不多10年了。上一次有这种到边缘的感觉，大概是03年。 |
| 返回顶楼 | |
|
发表时间：2010-10-27
最后修改：2010-10-27
是无法上生产环境的？ 这就痛苦咯～
也写了很多年程序， 这几年我最大的感悟是， 代码的可诊断性比代码的性能来的重要的多。 一旦系统DOWN了， 每行log都显得弥足珍贵啊～ 检查下lock 顺序吧。 lockA->lockB->lockC unlockC->unlockB->unlockA . 这话估计也是多余的了。 10年的程序员都知道这么干啊。 |
| 返回顶楼 | |
|
发表时间：2010-10-27
主贴的内容回复下：
这家伙挺没有经验的， select这个问题， 基本差不多， 10秒种就能确定的。strace 看下就明白发生什么问题了。 额。。 |
| 返回顶楼 | |
|
发表时间：2010-10-27
只有全面的了解系统，才能随意的改变代码，如果是接别人的项目，在不了解整个运行过程还是最好别乱改。
|
| 返回顶楼 | |
|
发表时间：2010-10-27
dump core 是可以关闭的，也可以在程序内部屏蔽该信号。
|
| 返回顶楼 | |
|
发表时间：2010-10-27
弄好了领导不会奖励你，但是弄坏了的话……hoho
|
| 返回顶楼 | |
|
发表时间：2010-10-27
很佩服LZ的勇气
代码如果还是正常运行，我是绝对不改 |
| 返回顶楼 | |
|
发表时间：2010-10-28
问题终于解决了。
锁死是因为内存管理出了问题。内存管理出了问题是因为我误以为cpuid是从0开始的。而实际上在这个环境里，cpuid是从4开始的。于是改了一行宏，在里面加了个-4，问题就解决了。 |
| 返回顶楼 | |
|
发表时间：2010-10-28
callofseen 写道 问题终于解决了。 锁死是因为内存管理出了问题。内存管理出了问题是因为我误以为cpuid是从0开始的。而实际上在这个环境里，cpuid是从4开始的。于是改了一行宏，在里面加了个-4，问题就解决了。 楼上很效率 |
| 返回顶楼 | |
|
发表时间：2010-10-28
抛出异常的爱 写道 callofseen 写道 问题终于解决了。
锁死是因为内存管理出了问题。内存管理出了问题是因为我误以为cpuid是从0开始的。而实际上在这个环境里，cpuid是从4开始的。于是改了一行宏，在里面加了个-4，问题就解决了。 楼上很效率 Can work or work well is a biggest problem. |
| 返回顶楼 | |
