程序员百度不出来的bug怎么解决

举个笔者经历过的例子:

一、不能百度也不能谷歌的BUG-背景

去年夏天的一个周末,泡好茶,在凉快的家里,笔者打开一个业余兴趣项目,准备优化下思路。

对于码代码,笔者毕竟不是吃这碗饭的,所以身上难免有一些不好的习气,比如喜欢开着项目源码,然后抱着一本纸质笔记本,通过笔的勾勾画画来思考编码相关的东西,并没有使用编码管理的那套东西。这大概是受从事投资多年养成的要点速记习惯的影响,总觉得纸笔的自由和迅速,远不是屏幕键盘能比的。

这个项目,虽说是业余兴趣项目,但体量还是不小(代码量还是有小二十万行了),不少业余时间都贡献给这个项目了。所以,工作时比较谨慎,不让家里的小孩靠近,生怕把茶水打翻酿成事故。

由于项目是跟办公有关,所以采用了混合编译,目的就是为了兼容VB/VBA,以便用户以更低的成本进行二次开发。VB/VBA在桌面开发中,有优秀的演示能力,所以有部分测试的Demo也用了VB。关注笔者的网友们都知道,笔者目前主要分享VB/VBA的高阶编程原理,其实主要就来源于该项目中对VB的探索。

大家都知道,VB/VBA的IDE,对于用惯了其他现代编辑器的人来讲,简直是灾难。其实是习惯问题,是惯性思维作祟,也可以说是懒的原因。习惯了,其实也没啥,笔者体验后也没有觉得像网传的洪水猛兽那般恐怖,反倒对其IDE源码调试功能颇为欣赏。所以,很多接口的功能性测试,更愿意用VB来进行。

笔者今天要讲的这个百度谷歌都没帮上忙的Bug,就跟VB/VBA的IDE有关。

二、不能百度也不能谷歌的BUG-诞生

笔者使用的是简体中文环境,VB/VBA的IDE对中文有良好的支持,中英文混用也是其他IDE的使用常态。但问题就出在这儿了,小写的字母l和数字1在简体中文环境里,尤其是在VB/VBA的IDE中,即便是放一堆比较,一个不小心也容易搞混。就像下图中,估计也没几个人能一眼看得出吧?

程序员百度不出来的bug怎么解决图1

就像这种,分得清?

如果位于变量名,函数名中,编译器能够帮助识别,因为这是一个技术性问题,能够被兜住。如果位于某个字符串常量中呢?如果恰好,数据的初始化和使用跨工程,跨进程,跨机器了呢?不巧的是,笔者刚好就遇上了。

或许,是因为要思考的问题有了答案,刚好有了告一段落的空闲。我竟然鬼使神差地同意了,还特地交代,不许碰爸爸的键盘。小家伙还信誓旦旦地说:“不会碰的,爸爸你放心吧”。看着小家伙懂事的样子,就忍不住抱起来放我大腿上坐着。

“BIU”她得意得大笑,我还没反应过来,就看见她的小手在键盘上按了下。而此前,我正在无意识地挨个用鼠标或双击或框住字符交替着玩,这是多年养成的坏毛病,就像很多人刷题转笔一样,都是专心思考的必备样式。

”不是答应了不碰键盘吗,怎么说话不算话?“我有些生气,将小家伙放了下去。”没有按,爸爸“小家伙的委屈劲儿一下子就上来了,几乎要哭,眼泪汪汪的。为了安抚,陪着小家伙,到外面玩了会儿,等情绪好了,重申了不能随便打扰的纪律后,赶紧回到电脑进行检查。仔细看了下代码窗口,使用撤销后,感觉屏幕范围内也没啥变化。”或许没按上吧“我心想着,就恢复到了最后状态,反正也记不清撤销查看异常前,到底有没有没有保存的修改。

等发现问题的时候,这事已经过去了一周。出问题的测试模块,是测试一段提升VB/VBA性能和安全性的ShellCode。关于VB/VBA的问题,笔者已在《早判了,VB已死,但我说话了么?》《

影响VB/VBA商业价值的原因是什么?

》《VB的无解,变现为首,质量其次,就这样了?》《VB/VBA这个打不死的小强,还会坚持多久?》《探秘,64位Office VBA能否与VB6再续良缘?64位VB6能否继续躺赢?》《VB当然能在64位Win上继续豪横!》《VB/VBA的IDE究竟需要什么?》等系列文章中有详尽的介绍,欢迎关注BtOfficer的后续分享。所以,为了解决好VB/VBA中的问题,就不得不从MSVC的编译器和链接器角度出发,难免不使用X86汇编来通络某些障碍。

测试的这段ShellCode就有这样的作用,在VB/VBA中以通常的方式(非VB圈网传那些奇技淫巧),提交项目的安全验证参数,来测验ShellCode是否达到设计目标。结果一测,坏了,根本就不让通过。而这一切,在前个周,也就是佩奇事件之前,均能通过测试。

直觉告诉笔者,出Bug了。脑袋瓜里迅速搜索,近段时间的参与情况,毕竟是自己全权负责嘛,门儿清。因为工作繁忙,添砖加瓦的事并不频繁,有改动的也跟测试的模块没有关系。赶紧启用已编译好的系统,又一切正常。VB测试模块里,源码调试,无需日志(就喜欢这点),可直接跟踪返回结果,但也仅有校验错误的提示。

这就奇了怪了,校验的参数一样,模块未改动,一边正常,一边不正常。正常说明ShellCode没问题,不正常说明测试Demo本身有问题。测试Demo本身有问题,那也是参数的问题,但正常和不正常的参数又是一样的。百思不得其解,这也没办法百度谷歌啊!莫非VB/VBA的IDE天坑,出来了?于是百度:VB是否会不稳定,类似于发神经的那种时好时坏?谷歌:VB6/VBA的IDE存在哪些不为人知的Bug?

当然是不会有答案的,只不过是病急乱投医,看看还有没有其他『受害者』。当年Delphi多牛,号称VBKiller,但依然没有干倒VB,应该是有一定道理的。按理,猜测中的神经质是大概率不存在滴,不然也不至于没有相似的案例。微软曾亲口说,VB6的IDE是健壮的。这点,笔者既信,也不信。

在既有的规则体系下,规规矩矩地使用VB/VBA,不碰指针和其他VB/VBA中隐藏的彩蛋,笔者相信VB是健壮的。无论是错误处理,还是源码调试,都能完美应对。但是要碰VB/VBA中的彩蛋,谁也给不了保证,就如同任何C的编辑器,能保证代码的健壮性吗?

Matthew J. Curland写的《Advanced Visual Basic》被奉为VB圣经,相信很多VB资深玩家都拜读过。他在书中描述到,测试该书中的结论时,VBIDE的崩溃非常折磨人。他建议要想AdvancedVB,熟悉理解底层操作是必要的。可见,一旦到了VB/VBA的非舒适区,VB/VBA就不再那么温顺。

随后的几天,笔者一直搜寻着VB/VBA IDE的真正缺陷,因为这样要容易一点。VB/VBA的源码调试和错误处理虽然功能强大,但它不能调试封装的二进制代码。使用调试器挂载VB程序和其他非VB程序,又非常麻烦(主要是代码本身的逻辑很复杂,又包含了反调试功能)。所以,迟迟不愿从根本上正视问题。

三、不能百度也不能谷歌的BUG-解决

就这样,又过了一周。期间的搜寻里,申诉痛斥VB/VBA的占绝大多数,真能说上几句的却极少。可能是VB6/VBA自2008年官宣停更IDE后,后继投入太少,也或者是大量专业开发人员弃用太久,关于VB自身的资料犹如凤毛麟角,很难寻觅踪迹。

无果后,只能打开调试器,经历自己亲手设定的痛苦(不仅要经受VB运行库的折磨,还要绕过反调试)。这是个费眼力,费手指,费脖子,费键盘的过程,但好在有空调,消去了不少烦躁。大半天后,终于跳到校验指令处。尼玛,寄存器里的校验值就是不一样,真乃校验错误啊,诚不欺我也!

明明一样的参数,为何一处通过,而另一处却不通过呢?VB/VBA的代码编辑窗口,在复制粘贴的时候,确实出现过不兼容显乱码的情况,这是编码格式的问题。那是否也意味着,某些时候VB/VBA内部的自动转码机制超期望启动了?毕竟,笔者也使用了指针,就是为了避免这种无效的转换。

无论如何,知道是参数的问题,就好办多了。而且极可能是参数编码的问题,导致传入的数据和最终使用的数据不一样。然而查看传入前后指令,并无转换过程。那剩下的最后可能就是,传入的参数看上去一样,但实际上不一样,比如包含了不可打印的不可见字符。

于是,单独对两份参数进行比较,果然不一样。肉眼观察了一遍,没见不同,但是代码比较却显示不同。这种神经质一样的现象,让笔者感到非常惊奇。最后,也是憋着一口气,逐字符比较。结果显示是”l<>1“,二者的ASC值也不一样。

1个是字母”l”,1个是数字”1″。在浏览器中看上去很明显,但在VB/VBA中,那叫一个迷糊,来来去去数十回,都没认出这妖怪。原来,就是家里的小家伙,按下了字母键l,替换了刚好被选中的数字1,再加之VB/VBA迷糊的IDE,一个肉眼难辨,网络难搜的Bug就此诞生了。

修改后,顺利通过校验。为了这个在字符串中的”l”和”1″,颇费周章,找到后有种大病初愈的感觉。笔者也在想,无论是按语法编码还是按芯片手册撸编译器,字符串永远都是最麻烦的。笔者所经历的这遭Bug,也算是印证了吧。

笔者曾在《VB/VBA字符串》一文中说,字符串在人机交互中,举足轻重,是站人这一边的,其作用甚至比变量和函数更突出。因为字符串,绝大多数都是以自然语言的形式出现在编码中的,用以弥补二进制的机器码和有限语义的高级源码在描述高维逻辑层面上的不足。

字符串是一个开放式的领域,超脱了计算机硬件,不是系统能兜得住的。如果在法律上,这种问题不会主动犯错而具有危险性,监管者就会采用不诉则不管的原则。对于计算机系统而言,同样如此。所以,真正难除的Bug,永远来自人类本身,因为没有上帝之接口,可供SetLastError,更不可GetLastError。

欢迎关注BtOfficer(收藏、点赞、关注+转发) ,更多精彩仍在继续哦(专栏文章将更系统,更全面,但需要阁下支持哦),有严肃的技术,也有轻松的唠嗑,期待你的加入!

作为一名程序员,找百度等来解决bug是挺正常的一件事,主要是为了能快速解决问题,毕竟许多问题bug可能是很多人之前碰到过,并且已经给出了不同解决方案方法的,有些甚至有现成的,大大提高了解决问题的效率。

除了百度上搜索不出来,可以尝试到Google、stack overflow、CSDN网站尝试查找下。

实在找不到,你也只能尝试解决,作为程度员应该要拥有调试程序解决BUG的能力,自己尝试模拟再现问题场景,逐步调试,慢慢发现问题,解决问题。或分析查理下可能产生此BUG的多种因素,分别去测试验证,尝试在其中分析问题,最后解决问题。

百度、Google、stack overflow等相关平台只是我们提高效率的辅助工具,但我们也不能因为相关平台找不到解决问题的方法就丧失了解决问题的能力。过度依赖相关平台,没了这些平台就不能解决问题了,这样的程序员是不合格的。

未经允许不得转载:百场汇 » 程序员百度不出来的bug怎么解决