社区昵称：巴洛克上校
我遇到的一个百度的彩蛋但是我认为他就是一个大BUG，昨天我想要找一张打雷闪电的照片于是在百度上输入了打雷二字，此时我正带着耳机但是没放音乐至于原因。。。。；就当我聚精会神的找东西的时候，只听耳机里突然轰隆一声巨响，这家伙给我吓了一大跳，鼠标差点让我扔了，看了一眼旁边同事正用怪异眼光看着我。。。。。。（这东西应该是那个调皮的程序员搞的恶作剧，还好我没心胀病要不底吓个好歹的）后来上网一查不如输入布谷鸟 黑洞 大风 换转 duang 海边 都有变换以前一直都没发现过；
之前还玩过一个联想的游戏类似微信的飞机大战，用手机玩几乎几下就Game Over 但是我发现用平板玩只要你想玩你就不会死，于是赶在周日我就用平板完了一整天连饭都没吃玩了13个小时，登上那个榜首可就在公布结果发奖时竟说我作弊取消资格，结果和他们好顿理论才恢复。（其实很多HTML5新游戏都是用平板玩很轻松）
还有mac版的优酷在看视频时候如果切换清晰度有70%的概率会直接崩溃
ios的通知栏在不特定情况下收到通知后，下拉通知栏里面所有的内容通通消失
社区昵称：szm.
最神奇的bug就是百度的验证码了，只要他出验证码，我就没输入对过??明明输入的是对的，却一直提示验证码输入错误，还好很多时候登录非刚需。
另一个bug是新浪的，之前它推出微盾，于是绑了账号，某一天手机恢复出厂设置，于是悲剧了，登录账号需要微盾验证码，还是非定期出现，有时候会让输，有时候直接可进入，注册时的手机号也没了，基本上这个号废了，可惜了。
淘宝也有bug，为啥我买了一件商品后给我推荐更便宜，看起来更好的商品，你这样良心不会痛么。
社区昵称：机器的心脏
昨晚刷的第二版，浏览器主页中间有个搜索栏，一直到今天下午都有，今晚打开浏览器不见了。。我记得之前更新第一版之后也有过这个情况。。
然后今晚重启之后桌面边缘出现个诡异的百度输入法图标，轻按它可以上下拖动，但往中间一拉就消失，只是锁屏又解锁之后又会出现。 如果重按住它，还会有一次震动感，然后居然可以拖着它满屏跑，放手它就自己缩回屏幕边缘——简直就像个电子宠物。。真是个诡异的Bug...
社区昵称：雪雪雪雪儿
在 2000 年的时候，项目组负责有关 JPEG 文件格式的工作，被称为 JPEG 小组，当时决定推出一个叫做 JPEG2000 的新版本。新版本有着很多很棒的想法，其中有一点是它支持流媒体图像。一张 JP2 图像可以包含多种分辨率，并且按照分辨率由低到高排列。所以，在你下载图片的时候，可以很快速的获取低分辨率的图片。这种特性的好处是，在网络状况很不好的情况下，浏览器可以迅速优先加载低分辨率的图像。同时，低分辨率的设备在匹配到适合它分辨率的图像后就会停止下载。
当时，JPEG2000 希望 JP2 图像标准可以被加入到浏览器中（剧透一下：很可惜，并没有）。我们想要用它来构建地图类的应用。JP2图像可以编码卫星图片，并且我们专门返回SVG地图的服务器。由于没有浏览器支持JP2，我创建了一个ActiveX控件，用来将JP2图像以流的形式转化为SVG地图。这真是太酷了，（在当时）我们的图像分辨率可是Google地图的十倍。
我用的是一个叫做 Kakadu 的第三方库。这是一个能够解析和将JP2 图像转化为流的开源库。Kakadu 的表现真的非常非常棒！ 它非常快！除了在使用一段时间后它会无征兆地卡住。这引起了我的注意，并且我怀疑问题产生的原因是用于存在线程竞争。所以，我决定通过 debug 来解决这个问题。在当时，我很年轻，而且对多线程的理解还算不错，但我还没有真正解决过一个多线程问题，是的，对此我很兴奋。
所以我通过深入它们的源码来开始调试。我记得在一开始开启debug进行调试的时候，问题竟然消失了。该死！事实上，调试器本身作为一个同步机制，它改变了线程中指令的执行时间。
于是我开始添加log日志输出来观察一下。在我添加log之后，问题竟然又一次消失了，我的天！由于日志信息记录到文件系统，文件系统作为一个同步机制再一次改变了指令的执行时间。
调试不行，添加log日志也不行。我还没有告诉你，这是一个多么复杂的大工程，所以，在我解决这个问题之前，我需要弄清楚如何在多线程环境中解决问题，该死！
于是，我开始思考，这会是由于同步机制以外的代码而导致代码的执行时间被修改么？所以说，只要我保持内外部代码一致同步，那我就有可能阻止执行时间被修改。于是，我开始尽量的减少log日志输出。最后，我懂了，如果我输出一个字符的log日志就不会出错，也就是说，log日志最多不能超过一个字符。
所以，第一件我需要弄清楚的事是，问题的发生与否是不是由于执行了不同的代码所导致的。要记住，最多我只能输出单个字符的log日志。于是，我开始深入分析每一段代码，而不是仅仅理解它的作用。每当我到达一个条件判断语句时，我会在两条分支上分别输出日志信息。其中一条分支输出“”，另一条分支输出“/”。当我看到一个循环语句时，我在循环体内输出“|”。当我看到输出的日志时，它是这个样子的
|||//|||||||||//
我会在运行程序的时候，分别记录下代码执行成功与失败两种情况下的字符串信息。下一步，比较两个字符串，找出不同的地方。最后，我会根据字符串信息中不同的地方，对应到代码中去进一步分析。
因为我不能输出过多的日志信息，所以我不得不仔细分析。幸运的是，Kakadu的代码结构非常好。我真想亲一口Kakadu的开发者（虽然他们制造了这个bug）。所有的代码层次结构都很清晰。它们通过高级方法来调用底层的方法。所以，我选择在高级方法中添加单字符log信息。当我找到差异时，通过代码我可以知道产生差异的原因。在大多数情况下，差异都是由于底层调用的方法不同而产生的。于是，我删除掉原有的log日志，然后在底层的方法中添加相同的log日志来观察，就这样，一层又一层，直到我找到产生bug的原因所在。
这整个过程花了大约三个星期。最后通过修改了一个字符解决了问题。由于渲染线程在等待生产者线程加载的数据，而形成一个循环等待，造成了卡死的问题。计数器在判断数据时，使用的是<而不是<=。通常，计数器会从预期的情况中，得到想要的数据，并且能够正常执行。在极少数情况下，当=条件满足时，渲染线程会过早的解析数据，造成异常，并跳出执行语句。从而导致渲染线程中断执行。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
