软件开发 说个面试常问题１ 各位来提供下答案

rommi

面试经常会问道debug方面的问题

比如：
1. call stack不完整的defect
2. end user report过来的defect 无call stack　有一些基本信息　比如函数绝对地址之类的
3. qa提供的一些defect　无稳定重现步骤但是有时候确实能重现

等等　类似于这些
各位如何回答？

catchmeifucan

想到哪儿就说到哪儿吧。
第三个来说，无法重新是一个非常常见的问题。好的系统本身应该是有一些log机制的。出现问题的时候至少应该收集到那些log从而能作进一步分析。基于现有的log来理解问题。如果的确无法进一步分析，就要考虑加入debugging code或者用GDB之类的辅助工具。一旦问题重现，争取要拿到所有的有用信息。重现问题的cost有时候是很高的。要尽量避免反复加入debugging code. 要问自己一下，如果你的debugging code或者breakpoint hit到了，你能够根据这些信息找到root cause 吗？

catchmeifucan

就当自己练习面试了：
第二个问题有点奇怪，从问题来说end user关心的是某个功能好不好用，而不是某个函数里报出了某个错误或者打出了某个log。假设用户同时提供了这两种信息（比如呼叫转移不工作了，同时log file中总能看到某个函数报错误。那么就要从这几条线同时入手：
知道某个功能出了问题，可以帮助你了解和重现这个问题。
知道某个函数工作异常，可以从函数本身功能，函数调用关系，以及函数外部入口来分析。

lol

直接回答我写的代码从来没有bug, 所以不存在这些问题。

cfk

第二个问题，gdb可以用没有strip过的binary和strip过的core dump连用的

cfk

第一个不完整肯定就是被smash了呗，基本上套上valgrind跑一下看下严重的地方就能找到内存出问题的地方了。

clarkli

1.call stack不完整可以尝试手工修复

2.有ip就可以拿map file看到哪一行出的问题

3.先让问题可以稳定重现

tristone

原帖由 clarkli 于 21-7-2011 22:50 发表

                               
登录/注册后可看大图

1.call stack不完整可以尝试手工修复

2.有ip就可以拿map file看到哪一行出的问题

3.先让问题可以稳定重现

最大的问题是，stack完蛋的时候，core的那一行绝对不是引起问题的地方。

这个问题很让人头大的。我们公司就有一个这样的bug，两年多来从没修好。不过我们的情况也非常特殊——问题99.99%出在第三方API里，但是我们没有这部分的source。除此之外我们用的RogueWave替换了glibc的内存分配器（据说快20%），所以valgrind的报告不可靠。而RogueWave专用的mdb灭有报告任何错误。

据说gdb7有回溯功能，不知道能不能有所帮助。

clarkli

原帖由 tristone 于 23-7-2011 11:07 发表

                               
登录/注册后可看大图

最大的问题是，stack完蛋的时候，core的那一行绝对不是引起问题的地方。

听起来很像是STACK OVERRRUN
WINDOWS下可以拿App Verifier去跑，LINUX下暂时还不清楚