大家遇到过哪些看起来匪夷所思的 BUG 最后靠自己解决的
- 0次
- 2021-06-01 13:04:11
- idczone
大带宽服务器
1. 成年了发现国家不分配老婆,
2. 毕业了发现国家没分配工作
3. 退休了发现.............
第三条通过不退休解决
通过 996 猝死解决
https://www.zhihu.com/question/34787444
知乎这个问题挺好玩的,程序员可以看来乐乐
第一个回答笑了,最后竟然是重启解决的,一种意料之外情理之中的感觉。。
很久没做 Windows 桌面应用开发了,最近写了一个(还用了一些 WIN32 API ),但是重复使用下,重置应用状态太麻烦了,改了半天总会出些奇奇怪怪的问题。
实在没办法了,每次用户点新的请求都自己重启应用,还是这样省事。
记一个由护手霜引发的 BUG:
http://www.debuggerx.com/2021/02/23/a-app-bug-caused-by-hand-cream/?from=v2ex
Google 自动翻译导致 UI 框架的 api 不生效,有够离奇吧
经常内存泄露,只能重开进程
很多端口,网络之类的问题,重启可以解决百分之 90 。
哇,这也太匪夷所思了
https://wtywtykk.github.io/2019/12/15/STM32-Flash-Error.html
未初始化变量+时序问题,找了好久才解决
https://sysprogs.com/w/forums/topic/bin-file-size-ecxeeds-flash-size-with-no-error/
链接脚本问题导致编译结果超过实际允许大小,离谱的是这个有问题的代码出自 gcc 的 manual,并且很多地方都直接沿用了。
csharp 方法重载的 BUG,好像是 4.5.1 的,如下定义的情况下,使用 methodName(new IEnumerable{1}) 实际上调用的是第一个重载,如果方法内没有业务逻辑问题就不大,我们当时运行了一个星期才发现录入的数据有问题,玩家积分全是错的,查了半天
public void methodName(Int32 v1,Int32 v2)=>Console.Write(v1);
public void methodName(Int32[] v1)=>Console.Write(v1);
public void methodName(List v1)=>Console.Write(v1);
Redis 小概率没有按设置的失效时间失效
结果是底层封装太老,分开设置值和失效时间
现在已经修复了,IEnumerable 只匹配 IList 或 Int32[],有前者就用前者,否则是后者
Heisenbug 一生之敌
4 月份我在写硕士毕业论文,最后几天用 LaTeX 排版,一边学一边实操。为了降低错误出现的概率,我把各个章节都放在单独的.tex 文件中,每次只排版一个章节。
前面几章问题都不大,稍微有点小问题都能解决,问题出在了第 4 章。第 4 章十分长,编译了好一会才看到编译器打印出了超过 100 条错误信息,编译失败。看错误信息,应该是语法错误,可是这么长的章节,到底是哪里有语法错误呢?
我先是尝试了一些之前就出现过的解决方法,结果还是编译错误;用 Google 搜索错误信息,尝试别人的方法也没有成功。这个问题从晚上 8 点开始,一直到 10 点多都没有解决,忙了一天脑子也不清楚了,我想就到这里吧。
然后旁边的同学提醒了我,能不能截取出一段最短的问题片段,这样就能缩小问题可能的范围。我一想对啊!先注释掉第 4 章的前半部分,编译看有没有错误,如果有错误就接着注释掉后半段的一半,如果没有错误就取消前半段的一半,这样使用二分法逐渐缩小可能出现问题的范围。
就这样,我最终锁定了一个单词,这个单词里有一个下划线。难道是它?查了一下才知道 LaTeX 里下划线必须转义!至此,这个问题终于得到了解决,我也终于能回宿舍睡觉了。或许这不算 bug,但是定位问题的思路我认为还是相当有意义的。
前端程序,有次重构把前后端请求的 promise 改成了 async/await 了,结果内存泄露了
反反复复看了几遍没问题,devtool 定位到方法后,尝试把其上面可有可无的 async 去掉,结果就好了
再去看 babel 转出来的代码,果然是它的问题,多了 async 就多了层闭包,而且隔了层闭包把一些变量抓住了,导致无法 GC,就泄露了
倒也不是内存泄漏,因为这个工具主要的作用是一个胶水工具,把几个第三方工具整合到一起,因此用一些 WIN32 API 把不同第三方工具弄到一个界面里( SetParent ),这其中又涉及到由于网络原因,某些第三方工具可能会打开失败,那么其他已经打开的应用就需要统一一起关闭,这里面处理太麻烦了。经常会造成整合的界面显示奇奇怪怪以及焦点获取有问题
在虚拟机里编译系统,一直编译出问题。查了查发现是虚拟机的核心数分配了一个,然后脚本获取核心数除以 2,导致只有 0 个核心数,所以就出问题了。。
前段时间遇到一个重构的项目,项目中有个表单提交的部分,目测我改的时候发现的那个 bug,没人发现,但是线上估计也没人用过。明明有个 form 表单,但是他不写 form 表单,导致整个组件没法用