FreeOZ论坛

标题: 软件开发说个面试常问题１各位来提供下答案 [打印本页]

作者: rommi 时间: 11-11-2010 14:01
提示: 作者被禁止或删除, 无法发言 标题: 软件开发说个面试常问题１各位来提供下答案
面试经常会问道debug方面的问题

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

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

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

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

作者: lol 时间: 14-12-2010 13:58
直接回答我写的代码从来没有bug, 所以不存在这些问题。

作者: cfk 时间: 14-12-2010 21:33
第二个问题，gdb可以用没有strip过的binary和strip过的core dump连用的

作者: cfk 时间: 14-12-2010 21:42
第一个不完整肯定就是被smash了呗，基本上套上valgrind跑一下看下严重的地方就能找到内存出问题的地方了。

作者: clarkli 时间: 21-7-2011 23:50
1.call stack不完整可以尝试手工修复

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

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

作者: tristone 时间: 23-7-2011 12:07

原帖由 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 时间: 25-7-2011 01:34

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

 登录/注册后可看大图

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

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

欢迎光临 FreeOZ论坛 (https://hioz.im/forum/)