当前位置: 首页 > 科技观察

那些怪怪的Bug

时间:2023-03-19 22:27:07 科技观察

并不能说所有的Bug都是纸老虎,但往往看似怪异的Bug,背后的原因却很简单,让你一时心烦,等你发现真相后,你会忍俊不禁。什么奇葩bug。我的定义是:代码逻辑一样,但是擅长A,不擅长B,或者同类的ABC好,但是D不好。最后,问题确实不在代码逻辑中,而通常在配置、权限或业务逻辑之外。本地没问题,但是服务器还是不行,怪我。case1:本地项目已经完善下推到服务端,但是过了一会,测试姐又来电了,“还是不行,你再看看”。顿时,他皱起了眉头,这怎么可能,他自己跑了一遍,就没事了。然后去服务器下推,再运行,就ok了。只有ccnet持续集成编译失败。挠着头想了半天。发现刚才跑的是debug版本,而ccnet跑的是Release版本。正是因为Debug写了一些配置,而Release没有,所以出错了。总结:不要一开始就忙,除了debug和Release。git上还有master、release、release、newFunction等多个版本。如果纠正错误,可能会导致更大的麻烦。case2:根据客户需求修改了功能。在放到云服务器之前,我会在本地IIS中发布并确认。但是有一次突然发现每次访问都要登录认证。如下图:明明设置了匿名访问,还给了IUSR_xxxx、Everone、各种权限,就是不行。本地是iis7,服务器是iis6,有什么区别?但是同目录下的其他网站是可以的。我按照正常的网站配置,还是不行,重新部署也没有解决。然后搜了各种帖子,想着肯定是跟权限有关,可能是某个文件,也可能是webconfig的配置,试了下发现还是无效。半夜,我静静地盯着屏幕。窗外,秋风徐徐,房间里,室友已经熟睡。突然有博主说IUSR_xxx账号可能没有AD权限,需要在匿名用户的地方设置一个有权限的账号。我改为xxxx/Adminstrator,它起作用了。但这是为什么呢?其他网站的匿名用户是IUSR_xxx就可以了,这样会不会有什么问题。现象解决了,但是还没有找到真正的问题,也许是某个程序,也许是某个文件。会继续跟进。总结:表面相似的人还是有自己的不同。但是这个问题只解决了现象,没有解决本质。case3:这个问题真的很奇怪。同事问我他的webservice无法调用。早上还好,下午就报407proxyerror。但是还是那句老话:“我可以调用其他服务,我可以在其他电脑上调用,但是这台电脑突然出现故障”。跟他测试过,api本身没有问题,网络也没有问题。问题,电脑没有问题,代码没有问题,因为根本进不去。哪里有问题?然后他的妻子(是的,他和他的妻子坐在一起)不小心在VS中打开了app.config。然后这个文件就显示已经被自动修改了,然后程序就可以运行了。我遇到过类似的问题。我有一个程序,每次用XDocument.Save方法覆盖一个文件,但总是不成功,即使VS提示:“文件已被修改,是否要重新加载当前文件?”我点击确定,还是没有改变,但是我删除了文件的内容。但是,它可以成功覆盖。然后同事建议我改成File.WriteAllText方法,就好了。总结:你有没有遇到过xml文件修改不成功的情况。或者频繁变化的文件不适合xml持久化?EF开的玩笑是这样的。为了让表格中的内容更好的展示出来,截取了半天的内容,发现用到的地方都改了,但是数据库没有改。foreach(varnoteinnotes){varstr=CommonHelper.StripHTML(note.Content);if(str.Length>15){note.Content=str.Substring(0,12)+"...";}}但未保存。但是当另外一个被捞出来的时候,内容就变了。raw=_respository.GetNoteById(id);但数据库没有改变。然后重启,先访问编辑页面,数据又正常了,明显是受了之前方法的影响。数据缓存了吗?后来发现是因为我聪明的做了一个单例,仓库里面的db=xxDB.GetInstance()。结果是因为两个页面都是一个上下文。数据被缓存,导致不是从数据库中查询对象。如果此时保存,其他缩短的内容也会保存在数据库中。最简单的方法是db=newdbcontext();总结:这纯粹是不了解EF的机制导致的麻烦,弄巧成拙。ckeditor不听话和同事做了一个异步加载编辑框的功能,发现有时候能加载成功,有时候不能。有些页面一直有效,有些页面并非一直有效。CKEDITOR.replace('Content',{toolbar:...});其实对于ckeditor来说,replace之后的参数id和name也是可以的.但是当时发现他的两个参数不一样,改成一样的话,都加载成功了。可能是某些页面正在干扰。还有一些“奇异现象”,我也说不清原因,就不提了。但是往往这些bug会消耗我们大量的时间。大多数能找到原因的问题都会有解决办法。找不到原因的问题是很难解决的问题。有时候即使解决了现象,也未必能解决问题的根源,所以我习惯记录这些事情,一旦发生,可能会发生第二次。这篇文章献给我们调试bug的零碎时间。