第三个来说，无法重新是一个非常常见的问题。好的系统本身应该是有一些log机制的。出现问题的时候至少应该收集到那些log从而能作进一步分析。基于现有的log来理解问题。如果的确无法进一步分析，就要考虑加入debugging code或者用GDB之类的辅助工具。一旦问题重现，争取要拿到所有的有用信息。重现问题的cost有时候是很高的。要尽量避免反复加入debugging code. 要问自己一下，如果你的debugging code或者breakpoint hit到了，你能够根据这些信息找到root cause 吗？ 就当自己练习面试了：
第二个问题有点奇怪，从问题来说end user关心的是某个功能好不好用，而不是某个函数里报出了某个错误或者打出了某个log。假设用户同时提供了这两种信息（比如呼叫转移不工作了，同时log file中总能看到某个函数报错误。那么就要从这几条线同时入手：
知道某个功能出了问题，可以帮助你了解和重现这个问题。
知道某个函数工作异常，可以从函数本身功能，函数调用关系，以及函数外部入口来分析。 直接回答我写的代码从来没有bug, 所以不存在这些问题。 :D 第二个问题，gdb可以用没有strip过的binary和strip过的core dump连用的 第一个不完整肯定就是被smash了呗，基本上套上valgrind跑一下看下严重的地方就能找到内存出问题的地方了。 1.call stack不完整可以尝试手工修复
2.有ip就可以拿map file看到哪一行出的问题
3.先让问题可以稳定重现 原帖由 clarkli 于 21-7-2011 22:50 发表 http://www.freeoz.net/ibbs/images/common/back.gif
1.call stack不完整可以尝试手工修复
2.有ip就可以拿map file看到哪一行出的问题
3.先让问题可以稳定重现
最大的问题是，stack完蛋的时候，core的那一行绝对不是引起问题的地方。
这个问题很让人头大的。我们公司就有一个这样的bug，两年多来从没修好。不过我们的情况也非常特殊——问题99.99%出在第三方API里，但是我们没有这部分的source。除此之外我们用的RogueWave替换了glibc的内存分配器（据说快20%），所以valgrind的报告不可靠。而RogueWave专用的mdb灭有报告任何错误。
据说gdb7有回溯功能，不知道能不能有所帮助。 原帖由 tristone 于 23-7-2011 11:07 发表 http://freeoz.org/ibbs/images/common/back.gif
最大的问题是，stack完蛋的时候，core的那一行绝对不是引起问题的地方。
听起来很像是STACK OVERRRUN
WINDOWS下可以拿App Verifier去跑，LINUX下暂时还不清楚
页:
[1]