主要观点:分享了两年前在工作中“假调试”一个多线程错误及昨天真正调试的经历,强调了“假调试”的危害及寻找问题根源的重要性。
关键信息:
- 多个用户随机出现“column "name" is ambiguous”错误,经调查是 SQL 查询构建器抽象的线程不安全实现导致。
- 最初认为是共享可变类属性
tables
引起问题并进行了修改,但后续发现并非如此。 - 两年后重新研究该问题,通过模糊测试(fuzzing)快速可靠地重现了错误,最终发现是引擎初始化时将引擎存储在全局字典导致的问题,该问题在代码重构为无状态后得到解决。
重要细节: - 举例说明出现错误的奇怪查询,如将 OAuth 表与 Pick List 表连接。
- 之前曾实验性地为部分用户启用多线程 Web 工作线程,回滚该配置后错误日志停止,暗示是多线程问题。
- 尝试各种调试假设,如打印
self.tables
的地址等,最终通过深入研究代码找到问题根源。 - 得出“假调试”有害,应努力寻找问题根源,在像 Rust 这样的语言中很难写出类似错误等结论。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。