有哪些讓你目瞪口呆的 bug?

問題描述:有哪些让你目瞪口呆的 bug?
, , , ,
Aorqu用戶:

這里有一個原理不算特別復雜,但是效果絕對拔群的bug

數字邏輯設計大作業,用Verilog語言寫的跳一跳小遊戲,其中有一個代碼邏輯是在VGA上繪制小圓球,應該的效果是在白底上畫一個黑色圓球,如下圖所示

然而,當我躊躇滿志的寫好下板之後,VGA上顯示的赫然是這樣的:

這樣的

以及這樣的

看起來很魔幻啊!很現代藝術啊!

一瞬間有想把跳一跳改成現代藝術生成器的沖動啊!

後來發現bug原因是,我的畫圓邏輯是(x-x0)^2+(y-y0)^2 ≤ r^2,但是我用了一個不夠大的wire變量來定義前兩項,導致離得較遠時溢出,就變成了這樣

這並不是遇到過最難調的bug,但絕對是最切題的了


匿名用戶:

Aorqu首答。

先說說背景,某企業普通實習生一枚。因為公司電腦資料比較多還需要保密,所以其他電腦都是設置了不能插U盤的,但是!我的電腦恰巧是整個辦公室唯一一台能插U盤的公用機,所以其他同事都會來用我的電腦拷文件。

每天日常就是被叫來叫去拷文件……

有那麼一天,我發現我電腦不能拷文件了……一拷就出現這個樣子

(大概就是這么一個意思)

……整個辦公室基本上只有通過內網機的內部共享互傳文件,而且如果你想通過電腦發往其他公司,還要通過外網機來發送,而外網機是進不了內部共享的,但是可以插U盤。現在如果我這一環斷了,共享文件出不來也就不能拷到外網機發送了。

於是幾天沒有人來找我拷文件,我把手頭上的工作做完了,習慣性插入U盤打算拷文件出去發郵件。因為文件在桌面,所以我很直接的就右鍵選發送到U盤。

大概就是這么個意思,我自己電腦上截的

然後加載完,成功,拔出U盤,發郵件,一氣呵成。

等等剛才是不是有什麼不對

我能拷文件了?????????

於是我又試了一下

不對啊!還是會顯示沒有權限啊???

打開U盤,對啊剛才發的文件也沒錯啊???

一臉懵逼的再次插入U盤,然後立刻右鍵發送至U盤,成功。

再一次,不成功。

??????????????????????

在我以為見鬼了的時候,我突然發現,每一次插入U盤,過多個幾秒鐘,右下角就會跳出一個窗口,內容:

【該插入設備為只讀狀態

管理員】

啥玩意啊……

等一下,那我拷文件和這個有沒有什麼關系??????

進行反覆試驗後,發現:插入U盤,未彈出窗口時拷入:成功;

插入U盤,已彈出窗口時拷入:失敗。

這是什麼沙雕操作嗎???????????????

原來還可以這樣的嗎???????????????

我是不是不小心發現了什麼bug啊?????????

趕緊拍了隔壁的師姐一把,「姐把你U盤給我一下」

「幹啥」

「幫你拷文件」

把一臉懵逼的師姐拉過來,給她操作了一遍。

師姐:

「你這是啥原理,再操作一次我沒看懂」

「很簡單……其實就是趁窗口沒出來拷就行了……」

「噢…………等等,趁????????」

「對對對……就是這樣……」

然後再給她試了一遍。

然後師姐看我的眼神都變了。

托師姐的福,那個難忘的下午。小辦公室里都知道了有個傻逼能趁電腦不注意把文件拷出來。

——————手動分割線———————

半個月過去了,你們真的很無聊……一個沙雕回答還能得到那麼多贊真的……

先感謝你們的贊,順便回答幾個問題:

1、不是手速快的小夥子,評論那位你猜錯了……

2、評論裡面那個 @文偉黃 還真是我同事……他和師姐一起震驚的我能怎麼辦……

3、師姐看到了,惹。

4、我已經實習結束離開好久了,並沒有追責,請放心,下一任也在趁電腦不注意。


Aorqu用戶:
想起了我們單位之前搞出的一個笑話:

「為什麼我們系統導出的文檔是亂碼?」
「還真是,文字是亂碼的,格式居然不亂!」
「我去!數據庫里也是亂碼的!」
「是嗎?我查下日誌……也…是…亂碼?!」
「你那介面編碼沒設置錯吧?」
「沒錯啊,都跑了好幾年了。」
一夥程序員圍觀半天,始終找不出bug在哪,最終一個老乾部路過,說了句:「人家這是越南文字…」
2018年2月23日更新:
經過反覆測試,解鎖【隱藏技能】:多語言支持
–經驗值+1
–系統適用性+5
–系統穩定性+1
–系統可維護性-1
–領導表揚+5
–工資+0


Bruce Luo:

咳,沒人說Bumblebee那個驚天bug么……一不小心就把你的/usr給幹掉了什麼的……

一個空格引發的慘劇

那個commit下面……

GIANT BUG… causing /usr to be deleted… so sorry…. issue #123, issu… · a047be8 · MrMEEE/bumblebee-Old-and-abbandoned · GitHub

好吧我是去收圖的hhhhh

可惜好多圖都掛了蛤蛤蛤蛤蛤

<del>作為當年受害者之一我怎麼笑得出來啊啊啊</del>


Aorqu用戶:

不是bug, 是design.

可能對於熟悉usb子系統的人來說這是常識. 不過我客戶報上來這個問題的時候我還是很詫異的.

3.0的U盤插3.0的usb口, 插快點兒就被識別成3.0設備. 插慢了… 就識別成2.0的設備…

大家可以自己試試看, lsusb -t 可以看出來這個設備被掛在3.0下還是2.0下…


賀顯偉:

蒂姆 庫克:「小鋒你去把TW站左上角的”Jobs at Apple”改成繁體字。」
小鋒:「老闆,換好了!」,


蒂姆 庫克:「……」


趙伊辰:

說一個機票相關的bug

機票,特別是國際機票,非常容易出bug,然而我要說的這個bug,是一些用戶人為算計出來的

每個機場,都有一個英文三字碼,制定機場代碼的規則我也不是特別清楚,但是,有個規律,那就是

幾乎所有加拿大的機場,都是Y開頭的

華人聚集地溫哥華是YVR,多倫多是YYZ,剩餘的不表

這個規律許多經常坐飛機的人都知道,甚至google都知道這個問題


既然加拿大的機場都是Y開頭,

那麼會不會有程序員偷懶,把Y開頭的機場,都當作加拿大的機場呢?


有一些精明的機票玩家就有了上面的大膽設想,他們認為

  • 會有一些偷懶的程序員,把Y開頭的機場,都標記為加拿大的機場
  • 溫哥華-某地-Y開頭的機場,就會被系統識別為加拿大境內機票
  • 境內機票的票價,燃油附加費,就可能大幅降低

其中,中國人想到的就是,有沒有什麼中國的機場也是Y開頭的機場代碼,並且加拿大到中國某地,同一個這個中國機場,也到某國中國的Y開頭的機場

考慮到加拿大是個民航市場很壟斷的國家,只有加航飛出加拿大的國際航班,加航到中國也只有北京(PEK),和浦東(PVG)兩個機場,而國航跟加航又都是星空聯盟。

於是這些人的目光聚焦到了國航的網站上面


在國航的網站上面,輸入Y,就可以找到國航飛的Y開頭的機場

最終他們發現了一個叫做 運城 的地方,這個機場的代碼是YCU

最終測試下來:溫哥華/多倫多-北京的加航航班後面,加掛一段北京-運城的國航航班,會被加航的里程系統當作加拿大境內的航班,里程數大幅降低

最終,人民幣1000多塊不到2000塊,就可以從溫哥華/多倫多坐公務艙到北京,美滋滋

然而,加拿大境內並沒有一個叫做YCU的機場,這就尷尬了


當我第一次跟一個從事並購重組的律師說這個故事時,這個律師驚嘆,以後我們搞收購的,應該從常旅客大神裡面挖人!


這個bug結合了幾個特點

  1. 數據錯誤。加航的里程兌換系統裡面對運城機場YCU的數據元素錯誤
  2. 運價校驗錯誤。機票系統裡面有一個常見的bug-proof工具是機票的里程距離檢測,就算上面的YCU機場被錯誤的當作是加拿大的境內機場,也應該計算多倫多/溫哥華-北京的飛行距離,加上北京運城的飛行距離,大約有接近10000公里了,遠遠超過加拿大境內的大約2,3千公里,在這里應該被抓出來
  3. 跨航空公司校驗錯誤。任何涉及跨航空公司的機票,應該都有一個額外的校驗,防止艙位代碼錯誤
  4. 系統性bug。只要國航/加航都有庫存,這個bug不死,長期隨便換。這可比什麼東航code share i艙字母用起來方便多了,堪稱know-how

對於旅客來說,這張機票有個問題,那就是:

我定了一張多倫多/溫哥華-北京,北京轉機去運城的機票,我能不能在北京下飛機,剩下不飛了?

這個問題略微復雜,結論是:

等你落地北京以後,一定是可以的。

請仔細揣摩這句話的含義,這句話裡面包含了「行李怎麼辦?」


坐1000多塊的公務艙到了北京,那回去怎麼辦?難道坐經濟艙回去嘛?

機票要按順序使用

溫哥華/多倫多-北京,北京運城,運城北京,北京溫哥華/多倫多的機票,按照全世界通用的規則,如果你從放棄了北京運城的機票,那麼之後的機票全部作廢,或者說不能直接登機

所以,比較保守的玩家,在發現溫哥華/多倫多-北京-運城的bug之後,實際上都是出的反向的機票,也就是

  1. 運城-北京
  2. 北京-溫哥華/多倫多
  3. 多倫多/溫哥華-北京
  4. 北京-運城

然後單獨購買一張北京運城的機票,去感謝一下關帝爺(運城機場全程運城關公機場,我還真去過哈哈哈哈,不過我是坐的國航北京-運城-昆明的經停航班,最終去的是昆明)

這樣他們的最終行程是

0 北京-運城,單獨購票

1 運城北京

2 北京-溫哥華/多倫多

3 多倫多/溫哥華-北京

4 北京-運城,扔掉

其中,0其實在機票玩家中還專門有一個術語,叫做positioning flight。I’m in position, 哈哈哈


事實上,由於加拿大航空跟國航的系統不是一個訂座系統,完全可以定一個

  1. 溫哥華/多倫多-北京
  2. 北京-運城
  3. 運城-北京
  4. 北京-溫哥華/多倫多

往返機票,然後直接在北京上下飛機。原則上,的確有所謂機票必須按順序使用,跳段使用機票作廢,但是由於預訂系統的同步延時問題,其實北京是可以直接上飛機的。

當然了,這個屬於高段位的操作了,比如這樣一張東航機票,裡面既有東航自己的航班,也有南航代碼的法航航班,還有南航代碼的南航航班,就因為預訂系統的同步延時問題,就直接跳段使用了


這個bug我知道,但是從來沒飛過,非常遺憾.

其實,機票bug經常有,大陸國外甚至都有網站專門播報,我之所以認為這個bug讓我目瞪口呆,因為他是旅客自己故意下套,讓機票系統鑽進去,而不僅僅是機票系統自己弱智.

後者的例子很常見,例如,曾經有一段時間,用某航空公司的里程兌換機票時,只要勾選必須強制漢莎航空,北京-吉隆坡的機票,就能跑到法蘭克福去轉機,這樣北京吉隆坡的頭等艙只要2000多人民幣就可以坐頭等艙吃魚子醬喝克魯格,還能薅出來2個甚至4個8個rimowa洗漱包上鹹魚賣個2000多塊

而且這個bug似乎是個”公開的秘密”


免責聲明:

機票扔票是高危行為,輕則不讓上飛機,重則補交票價差額,或者後程機票作廢,切勿輕易模仿


默念寂寞:

前幾天老婆在某某匯買了個SKG的養生壺樣子如下

功能很多

說明書上詳細解釋了每一樣功能的加熱方式和程序,(程序設定大致為,加熱到100°,然後轉換為90° 10分鐘後再加熱到100°,總之就是各種不同溫度,不同時間的組合。)老婆高興的想終於可以無人值守的熬薏米紅豆水了,高興的加了水,把東西加進去,開心的逛街去了,等我回到家已經是兩個小時以後,粥溢的到處都是,壺裡面已經沒有一滴水,高溫自動斷電了,我想著不能耽誤老婆減肥,就收拾乾淨以後又換了一壺原料,結果幾分鐘後水開後,一直不會跳轉下一個程序,結果讓我發現了一個BUG,無論哪種加熱方式,它的程序裡邊兒第一步都是把水加熱到100°,而我們這裡海拔750多米,水98°就開了,也就是說它不管使用哪種加熱方式都不可能把水加熱到100°切換到下一步。
結果就是200塊錢買了一個能定時的電熱壺,一切華麗的程序都因為這個BUG徹底卡死。這應該是你們海拔低的城市的人永遠都遇不到的情況,我也是醉了。


狂奔的蝸牛:

必須硬答一波了,這個bug找到原因的時候我簡直要死了。

本人在某外賣平台負責前端工作,碰到了一個臨時大項目,需要把原來平台的老代碼遷移一部分功能到新平台中,我負責的就是物流相關模塊的代碼。
開發過程中碰到一個莫名其妙的問題就是頁面在展示物流配送區域的地圖時候原本應該展示的地圖加載不出來,正常的效果應該是這個樣子的:

然鵝實際出來的效果卻是這樣子的:

碰到bug本來是很正常的問題,不出bug才不正常呢,開發過程中最怕的就是遇到這種第三方組件庫運行不正常的問題,因為你也不知道這個問題是出在你這里還是組件庫出的問題,定位問題就要了老命。

於是我找到了地圖官網網站,把需要的所有介面的API文檔都看了一遍,每個需要用到的欄位都核對一遍,然後逐條對比兩邊數據,然後發現不管我怎麼折騰特么的地圖展示的永遠都是藍色背景。

???WTF?

從下午一直折騰到晚上還沒弄好,正當我自暴自棄懷疑人生的時候無意碰到了鼠標的滾輪,於是地圖縮小了,突然我就發現地圖中出現了除了藍色背景之外的東西,然後我繼續縮小就發現地圖從始至終都運行的正常的,之所以背景全是藍色是因為特么的這是海洋,後端哥們取不到上游的真實數據就隨便給我寫了個經緯度0 0 的數據,給我定位到大西洋了。

頓時我怒從心頭起,惡向膽邊生,站起來就要打人,一看周圍就我一人了,再看時間已經兩點半了,對接的後端哥們早就跑路了,沒辦法只能一邊提醒自己趕緊回去睡覺,一邊提醒自己明天上班別忘了帶刀。。。


M3小蘑菇:

《騎馬與砍殺》天空貼圖錯位成了人物臉部貼圖


銀河暗山:
西安某高校的宿舍供電系統。
首先介紹一下設定:
勞動節到國慶節這五個月全天宿舍不斷電(不欠費的情況下)。而從國慶節到次年勞動節這段時間,每晚23時30分宿舍樓斷電。但是很明顯是人工斷電的,因為每晚斷電時間都有差別,不同樓也是先後斷電。
如果欠費可以去人工櫃台繳費,也可以通過網上的系統繳費。網上繳費系統每天凌晨0點10分維護完畢可以繳費,但是一天只能繳一次,最少買一度電。一般繳費之後需要處理五六分鐘會給電。
看起來很正常對吧?
然而,繳費之後給電這個操作居然可以無視整棟宿舍樓已經斷電的前提條件。所以最後的結果就是整棟樓只有我們宿舍有電!
這個發現來自於一次騷操作。某天半夜我閑得沒事干在網上繳了5毛錢電費,幾分鐘後居然來電了…冷靜分析…稍加思考…識破!
第二天晚上,23點30分左右,宿舍照例斷電。我迫不及待等到0點10分,去網上繳了電費,然後估計時間差不多了就急忙打開宿舍群。

我說 要有光 就有了光


Fireman A:

在我們的ERP系統里,有一個程序A天天向另外一個程序B發送Log,程序B負責解讀Log, 然後如果符合某些業務條件就觸發自動電郵。

程序A和B 自2008年開始運行就一直沒毛病,但是2013年一月一號程序B掛了。無論如何重啟,它也無法再處理A送來的Log了。

查Bug的結果是A的Log文件中日期欄位是以YYYYMMDD格式書寫的,但B是以DDMMYYYY格式解讀的,所以當他第一次讀到13月時就掛了。

坑爹的是其實B的業務邏輯根本不在乎日期,所以一直以來把後四位MMDD當成年份(0308年?1024年?)也沒問題。

我對此印象深刻是因為我元旦假期凌晨被叫起來修Bug。。。


攻城獅小武:

轉發一個之前看到的:鏈接文字在

《我聽到過的最精彩的一個軟體糾錯故事》​www.vaikan.com

那還是80年代初期,我爸爸在一家存儲設備公司工作,這個公司現在已經不存在了,它生產磁帶機和驅動這些磁帶高速運轉的氣動系統 —— 這是那個時代的產物。

(Used under license from Laughing Squid. 原始圖片可以在 這里找到。)

他們技術改造了磁帶驅動器,使得你可以只有一個中心驅動器 —— 「A」盤 —— 由它連接著數個「B」盤,在跟A盤連接的內存里駐留這一個小型的操作系統,負責代理所有B盤的數據的讀寫操作。

每次當你啟動A驅動器,你需要在外圍驅動器里插入一張軟盤,操作系統會把A盤加載到內存里。這個操作系統簡單的出奇 —— 它的處理能力全部從一個8位元組的微型控制器產生。

這種設備的目標用戶是擁有大量數據的企業 —— 銀行,雜志等等 —— 他們需要列印大量的地址簿或銀行帳目。

有個客戶出現了一個問題。在列印的過程中,有個別的驅動器會停止工作,導致整個列印過程終止。為了重載驅動器,值班人員必須重啟所有驅動 —— 如果這種事情發生在一個6小時的列印任務中,大量寶貴的計算機使用時間都會浪費,整個任務將不能按時間完成。

公司派出了技術人員。技術人員盡了他最大的努力也不能在測試環境復制出這個問題:這個問題似乎只會出現在列印大量任務的過程中。盡管問題出在硬體上可能性微乎其微,他還是更換了所有的設備 —— 內存,微處理器,磁盤驅動,所有跟磁帶機相關的部件 —— 但問題仍然出現。

於是技術人員打電話給總部叫來了一位專家

專家要了一把椅子和一杯咖啡,坐在了計算機房 —— 那個時候他們已經專門為計算機提供了機房 —— 值班人員準備了一大堆的列印任務,他就在旁邊看著。他等著,一直到機器崩潰。機器果真崩潰了,所有人都看著專家 —— 專家沒有發現任何的線索。他命令把列印任務重新執行一次,所有的值班人員和技術人員都回各自崗位工作。

專家又在椅子上做下來,等著機器崩潰。這一等就是六小時,但真的又發生了。專家仍然沒有弄清是什麼導致了崩潰 —— 除了有一點他注意到,崩潰總是發生在屋內人比較多的時候。他命令再列印一次,重新坐下,等著。

當第三次崩潰時,他發現了一件事情。崩潰總是在值班人員更換其他沒有關聯的啟動盤時發生的。進一步研究,他意識到當一個值班人員走過某塊地板時崩潰就會發生。

地板是由鋁制的板塊拼成,下面有6 到 8 英寸高的隔空層,計算機所使用的大量的電纜都走地板下,這樣可以避免值班人員無意間踢到它們。地板塊間拼合的很緊密,這是為了保證垃圾不掉進電纜通過的空間。

專家說有一塊地板變形了。當值班人員踩著這塊變形的地板的一角時,地板塊的邊緣相互摩擦,這就會跟連接各地板的塑料之間產生靜電,進而造成電磁干擾。

如今所有的RAM都有防電磁干擾功能。但當時並沒有這種技術。專家指出,電磁干擾破壞的RAM的工作,操作系統也就崩潰了。

專家打電話給維護部門,拿來了一塊新地板,他自己把它裝上,問題就這樣解決了。


wkGCaSS:

大學時候,有一陣子,我的筆電,把它拿到宿舍外面,比如教室、圖書館、工作室,都可以正常使用,一拿回宿舍右鍵就會被鎖死。具體現象就像右鍵一直被按住一樣。

我強制關機換到windows下,發現一切正常,再切換回來,右鍵又鎖死了。

因為不影響使用就這么持續了將近一周。

有一天突然想到,打開宿舍櫃子,拿出裡面的背包,把裡面裝著的藍牙鼠標關掉。。。

就解決了= =

原因是藍牙鼠標一直開啟,而且被周圍的東西壓住了右鍵。。


Aorqu用戶:


老狼:

iPhone手機日曆有個嚴重的bug

眾所周知1900年是平年,不是閏年,而iOS的日曆似乎是簡單的4年一個閏年的演算法算閏年的。這么大的bug怎麼沒人發現呢?iOS11上還有。

應該說計算閏年還是很簡單的,4年100年400年等等數據判斷一下就好,結果還是出錯,蘋果工程師的水準哪去了?

=========10/10/2017 更新=================

評論區裡面同學的回復促使我詳細調查了一下,更新如下:

微軟1900年站在了正確這一邊:

我是不是該大喊「微軟大法好!」了?慢著,當我打開Excel,輸入2/29/1900,它會認為是個有效的日期,並將其轉化成29-Feb-00,就如同我敲入2/28/1900一樣。而如果我輸入2/30/1900,則被認為是個無效日期而忽略,如下圖:

看來微軟也是自相矛盾啊。這是為什麼呢?我決定搜索一下,發現這還真是個冷門的問題,關鍵字應著寥寥。不過終於被我找到了答案,原來微軟Excel和iPhone的bug起因還不一致。

微軟Excel

在PC開始出現的初期,IBM的Lotus 1-2-3是PC的殺手應用,它被認為是PC所以成功的因素之一。Lotus 1-2-3紀元(epoch)從1900年開始,所以第一天是1900年1月1日,其後所有的日期都是在它上面加一個Delta差值,這也是為什麼我們上面1900年2月28是的年份表示是00的原因。Lotus從誕生起就有個bug,它認為1900年是閏年!

微軟因為Lotus的大賣而自己研發的表格系統Multiplan,它和它的繼任者Excel為了能夠與Lotus兼容,不但要做到外觀十分相似,而且為了能夠讀取Lotus的文件而故意引入了一樣的bug:將1900年設定為閏年!他們甚至聲稱這不是一個bug,而是一個feature!這真是Bug for bug的高度兼容啊。

包袱一旦背上就很難卸下,在Lotus早已作古的今天,Excel為了與以前的Excel兼容,還在繼承著這個」feature」,我們參考資料[1]裡面有微軟的官方解釋。

Apple

在古老的Apple I誕生之日起,蘋果的紀元就是從1904年1月1日開始,它用32bit記錄了從那之後的秒數,所以老的MAC系統最大能夠記錄到2040年(新的MAC擴展了位數)。而1904年之前則是通過簡單的4年一個閏年的方法倒推到之前的年份,所以1900年被錯誤的認為是閏年而2100年不會。這種方式也被iOS所繼承。後期因為兼容性問題,不做修改。曾經有人報告給Apple這個iPhone上的Bug,Apple的開發者未有回應(參考資料[2])

參考資料

[1]: https://support.microsoft.com/en-us/help/214326/excel-incorrectly-assumes-that-the-year-1900-is-a-leap-year

[2]: https://discussions.apple.com/thread/5982489?tstart=0

[3]: 《軟體隨想錄:程序員部落酋長》

另外此文被整理髮表在專欄:UEFI和BIOS探秘

也許是最冷的電腦冷知識:1900年閏年Bug

其他更多文章,歡迎大家關注本專欄和用微信掃描下方二維碼加入微信公眾號”UEFIBlog”,在那裡有最新的文章。同時歡迎大家給本專欄和公眾號投稿!

用微信掃描二維碼加入UEFIBlog公眾號

Aorqu用戶:


李二:
今天在寫一個很簡單的功能時,突然遇到了一個很奇怪的bug
沒錯,左側邊距不對勁,文字顯示不全,明明什麼都沒寫,卻看著像負值的效果。
本人雖然不是很擅長調ui,但是這種簡單的布局怎麼也不可能出錯。於是各種辦法都試了試,xml來控制邊距,java來控制邊距,甚至都去看textview怎麼ondraw的,一直也毫無進展…知道後來我撕下來手機的保護膜…

這大黑邊,坑人呢。。。。

發表迴響