Hari Jiang's Mind Palace

About Blog Email Feed

26 Sep 2014
G的悲剧

到公司后就被同事抓到,表示交付的软件有bug。我第一反应很惊讶,这不科学啊!昨天还是好的/在我机器上还是好的 ,怎么可能莫名奇妙的出现bug?

我考虑了下,前几天merge了下upstream,然后升级了开发环境,难道是merge的代码有问题?逐行对比下发现涉及到的代码没有任何merge,反复重试了几次还是有问题。因为这段代码会download到受限的客户端执行,所以很难debug。

这时想起了之前对开发环境做过快照,立刻恢复,重试。正常工作!再次把更新后的代码覆盖上,重试,出错!

已经能够重现错误!这就代表错误就在更新的代码中!对比了下代码….崩溃..没有变化…

没错..之前用到的代码根本没更新,代码是一样的..怎会出错?

没办法了..只能祭出法宝。

波若波若密!!恢复快照!!

这次是有备而来,apt-get install git 切换到项目目录, git init 覆盖更新的代码

没错!这次我打算用git来对比更新前后的代码,比肉眼靠谱得多,在这里我用了git的gui工具tig 用tig查看发现…代码看上去都一样!!但是git diff却显示不同..

用cmp -b byte by byte试着比较了两个文件..发现换行符不同.. 结论就是windows下得换行符导致代码在受限客户端运行出错..

WTF!!?为什么之前的程序可以正常工作?我在windows下得开发环境没换过啊

这时看了眼sourceTree突然明白问题所在..

git有个autocrlf的选项,设置后git会把提交的代码的换行符从dos style转换为unix style所以之前的代码正常运行

但是我在更新代码时因为机器连不到git server,所以我在windows上直接打成tar包。这时造成打包的代码没有经过git,所以没有被转换,保留了\r\n的换行符,造成bug。

正确的做法是我应该找一台可以连接到git server的*nix机器,在上面clone 然后打包。

终于找到了bug原因,我眼角湿润,望着上海凌晨四点的街景(此处夸张!)感叹,老子这一天就被这么浪费了….

bug的原因因为git的crlf被掩盖,而我又用到了git来debug,真是成也git,败也git..

遂效仿各大”悲剧”系列,以G的悲剧为题..


Til next time,
Hari Jiang 2014.09.26

avatar

About Blog Email Feed