你目前寫出的最大的 Bug 是怎樣的？

01-01

歡迎大家自爆～
詳細介紹一下，特別是影響和後果是什麼～
＝＝＝＝補充更新＝＝＝＝
因為大家來自不同的領域，可能有的梗需要詳細解釋一下，歡迎大家說的細緻一點

盡量把bug限制在自己寫的或者親身經歷的部分，不然就變成我聽過的最大的bug了～
對後果的描寫大家都很輕描淡寫嘛，特別是之後如何補救的，歡迎更多猛料233～

不是我寫的，但很有意思。Azure底層fabric有過這麼一段code，目的是檢查一張證書的有效期是否在一年以內。

那麼要先獲得一年後的日期，本來用DateTime.Today().Add(new TimeSpan(365,0,0,0))就可以了（編輯：經提醒，AddYear(1)是最簡單而且更精確的）。寫代碼的哥們腦洞了下寫成new DateTime(today.Year+1,today.Month,today.Day)。

經過各種測試運行一直都沒問題。直到2012年2月29日，ArgumentOutOfRangeException。

後果是整個Azure掛了十多個小時吧。

----------------------------------------------------------

編輯：關於這次outage，Azure官方的說明在這裡： Summary of Windows Azure Service Disruption on Feb 29th, 2012。有興趣的可以看下，細節都是公開的。

有些地方我記錯了，比如這段代碼其實是在做創建一張新的證書並設置有效期為一年後這件事，而非檢驗證書有效期。

很多人點贊，我交代一下背景和解決方案吧，希望能幫助到別人。

背景：這種通過跑sql來更新數據的事情不到萬不得已千萬不要做，當時是因為一個bug有一個客戶賬戶上的錢出了問題，因為bug需要1小時以上才能解決修復到生產，於是我決定去跑sql了。（以前這麼做過很多次。。。）

關於transaction：下面很多人說，資料庫是auto commit，我也沒有用start transaction，當時覺得只是更新一個row，也沒想太多（做過太多次了）

修復：

1. 第一時間，直接報告直屬上司，描述情況及解決辦法

2. 快速發布一個版本，隱藏掉用戶可以看到現金的部分，如果有客戶電話來了就說顯示頁面有bug我們正在修復（寧可不顯示金額，也不能顯示一個錯誤的金額）

3. 通過上線第一天起每個公司的收入支出每一筆交易算出正確的現金額。

4. 更新公司的現金額。

5. 重新發布，顯示現金。

反思：

1. 從此之後每一個sql需要code review

2. 不再給其他部門後台，如果有bug，修復bug

3. 對於這種set不給賦值常量，客戶本來是1000，顯示900，即使需要update也做update account_register set available_cash = available_cash + 100

4. 當做有風險的時候，準備好back up plan

=================原答案=============================

update account_register set available_cash = 1000; where id = 1205

想像我的渾身顫抖的狀態吧（平台上有幾千個賬戶幾千萬的現金吧）

在展開 Beta-redex 的時候有時沒有正確維護作用域導致丟變數

在一些非常刁鑽的情況下會把 if 的兩個分支給編譯反順序

爆過超算的內存

嘛其實這些都是小問題，我要不要去圈那個做軍工的來，那傢伙飛機大炮火箭導彈什麼都弄……

我以前同事給北京電信做催費的項目。就是你電話欠費的時候，系統會自動打電話給你，播放一段段語音：「xxx，請及時交費」之類的。當時他寫了一個測試數據「12345678」。後來項目上線的時候，忘記刪掉了。而當時，北京市長電話是「12345」。。。。。。然後，就悲劇了。

我的課題有關GPS自動導航，程序中忘了添加在GPS沒有信號時讓電機停轉的代碼。

然後在那個陽光明媚的下午GPS突然就沒有信號了，然後我們的小車以全速歡快地奔向了台階……

後兩天我們都在修車……

mv -f opt /home/xxx/敲成了rm -rf opt /home/xxx/

覺得自己相關的bug不夠勁，補一個：

bug造成一個國內娛樂圈的頂級上市公司戰略受挫。

王長田：光線已經不是原來意義上的電視節目公司，儘管這是重要的業務基礎。我們現在是非常國際化的傳媒、娛樂公司。外界過分誇大了新媒體對我們的意義，誇大光線對新媒體的依賴。我們是最重視新媒體，它未來會有很大市場空間，我們但始終認為新媒體只是渠道一種，未來也不能替代其他渠道，電視仍然是最大渠道。

　　我們新媒體主要發展互聯網視頻，但這塊現在技術條件、市場條件還沒有成熟，沒有人真正賺到錢。我們曾經作的很成功，後來用戶資料庫丟失導致網站排名大幅下滑，這個意外事件導致我們戰略受挫。後來嘗試去彌補，想過重新發展，但效果不理想。

附：印像中是一個程序員的bug或誤操作

獨家專訪王長田：光線華友合併十大熱點話題

====================================================================

原貼如下：

下面列的都是我負責部門發生的：

1、ussd業務，不停的給用戶發簡訊，造成用戶手機無法使用。

2、計費系統出錯

計費系統：系統定期把定購信息送給運營商，然後運營商扣費，然後運營商給用戶送贈送的流量包。

裝新伺服器的時候，小夥子沒有安裝相應的角本，結果訂購用戶都是免費在使用，但因為免費用戶運營商不送流量，給大量用戶整出了一個天價的流量費。

最美好的bug:

做手機證券的時候，某一個手機型號的版本：在特殊的情況下，k線會出一個奇怪的形狀（bug）;

有用戶把這個形狀當成指標，賺了多錢。

後來版本升級之後，這個bug消失了，用戶投拆。

寫過一個直接修改磁碟扇區內容的程序。本來打算對軟盤修改的，結果手賤，寫成了c盤！

理財產品展示的收益率大了100倍，買50000的年化收益率570%。

==================UPDATE 說說影響吧======================

錯誤的數據總共展示了12個小時, 這是在國內某個巨大的銀行首頁展示的, 大爺大媽看見估計都要瘋狂了. 個人金融部門的同事是真瘋狂了, 不知道客服的小姑娘們是不是也瘋了.

上線前的半小時改了一個小bug，要頁面一個列表的item根據它index排序，直接強轉int然後排序。

因為系統模塊化，小組分工。我們這邊index萬年都是數字型字元串，完全不知道另外一個系統可能導過來字母index。而知道這些的美國team此刻正在凌晨酣睡。

於是某巨頭網站的全球銷售系統癱瘓了三個小時。

第二天早上我被電話吵醒，然後發現收到了400封來自世界各地的郵件....

====================苦逼的分割線===============

其實這段代碼不是我寫的，是因為新來的一個哥們帳號許可權還沒開通，用我的帳號checkin的。

這也是為什麼我被抄送在四百封郵件里。= =！

看了 @謝小龍的那個, 表示還不夠狠... 最狠的是這個

# rm -rf / tmp/xxx

不請自來，公司年會抽獎那塊是我寫的，就是上下滾動的那種，平時自測的時候挺好，結果現場就停止不了，全公司五百多雙眼睛盯著大屏幕，當時我就覺得完蛋了，天塌下來了，後來大神做了個臨時解決方案，現場才得以正常抽獎，最根本的原因就是按鈕沒有做鎖定，現場操作人員又用了雙擊，結果導致兩次請求。我想說，bug不在於大小，在於影響面積有多大。匿了……

好像沒有特別大的BUG，說一個印象比較深刻的。

有一次，在oracle上寫了一個存儲過程，然後設置了一個JOB半夜來定時跑。

第二天星期六，本來說睡個大懶覺的，一大早就被電話吵醒了，說系統沒法用了，登入不了。

我當時暈乎乎的，想怎麼可能有問題，前一天就做了這麼簡單的一次修改，是不是伺服器出問題啦，然後聯繫DBA一同看問題，找來找去，結果發現，原來資料庫空間滿了，一晚上莫名其妙的增加了50多G的數據。

趕緊叫他在後台把資料庫空間加大，先讓系統能用再說。

我再登入進去看，呀，怎麼那50多G就是增加在昨天寫的存儲過程要插入數據的那個表。

認真檢查了一遍代碼，好像沒啥問題啊，測試機上跑一通，也沒錯啊。

有些莫名其妙，就說去把JOB先停了，點進去一看，咦，怎麼JOB還在跑，就一直沒停過？

再定睛一瞅，坑爹啊——原來那JOB的時間間隔設置錯了，一天執行一次，要設置成sysdate+1的，我給寫成了sysdate，相當於每次一執行完接著又立馬執行，不停的循環。

默默的把JOB關了改掉，多跑的數據也給刪了。

到了下周一開會，領導問起異常原因來，我輕描淡寫的說，哎呀沒什麼大事，就是資料庫空間滿了啦，加一下就好了……

會後，繼續敲代碼，根據另外一個差不多的需求，也寫一個存儲過程，設置了另外一個JOB半夜跑。

第二天一大早還沒睡醒，電話又響了，說系統又用不了了登入報了跟周末同樣的錯……

寫了個死循環測試了一下給老總發了一萬條簡訊被炒了魷魚算不算

2010年的陽曆新年，是我工作之後經歷的第一個新年。充滿幹勁的我，還夢想著不用多久我就會升職加薪，當上總經理，出任CEO，迎娶白富美，走上人生巔峰。想一想還有點小激動，結果因為一場突如其來的BUG，我陪著程序、客戶和一大堆的財務數據玩了一次跨年。

我們項目組接了一個ERP的單子，其中有一項工作是和用友的財務系統做對接，那個時候沒有webservice這麼好的條件讓我們來調用，用友採用非暴力不合作的態度不對我們開放介面，就連客戶也勸不動他們。於是乎，客戶說玩點暴力的吧。

你們能體會當時我們那種躍躍欲試的興奮嗎？

我們靠著程序員的耐心，一張資料庫表一張資料庫表的把用友的全部的資料庫結構搞了個明明白白。然後，我們強行的和財務系統做了資料庫聯動。

結果，所謂的BUG就在這兒潛伏起來了。

2010年的陽曆新年，正當我要倖幸福福的打場dota，慶祝我辛勤又美好的一年的時候。客戶的電話來了：「你們怎麼搞的啊？我們年底要扎帳的啊，數據對不起來了，程序太不靠譜了吧?」

當時我就懵逼了。我們項目經理剛和女朋友搞的火熱，還沒放假就提前半天走了，我一個剛出道的小弟遇上這事……

於是，我火速趕到現場（誰讓我沒有女朋友呢？）。

然後就看到客戶心急火燎的說：「今年的賬目，在你們系統里和財務系統里整整差了1毛多錢你知道嗎？」

我就感覺這多大點事啊，我給你兩毛不就完了？

客戶就開始苦口婆心的教育我，孩子這不是你給錢的事，這是大事。對不起帳，巴拉巴拉巴拉。

然後，我們老闆和公司的技術總監都被客戶電話叫到現場了。然後，我們老闆就開始打項目經理的電話。（喂，人家在做人生大事，能不能不要這麼不識趣？）

我說，報告老闆。我感覺我們可以這麼搞……

然後，就是數據還原，然後就是一張張的對財務單子。

整整從晚上6點弄到早上5點，單子才對完。尼瑪奇葩的事，一張單子都沒錯。我嘞個去啊，我那心啊，唉不提了。

然後，我們就鬱悶了，什麼情況呢？每個月的數據都對，一年的數據湊起來就錯了。搞什麼飛機？難道有鬼？然後，我們老闆說，我們是搞科學的要相信科學。

萬萬沒想到，最後我還是成功了找到了BUG，終於當上了公司的副總、雖然還沒出任CEO但是迎娶了我媳婦，也算是走上了小巔峰吧。

什麼你問什麼BUG？

你能相信，我們的ERP保留了小數點後5位，而用友只保留4位嗎？分之後保留5位和分之後保留4位，數量大了之後，數額會不同你能想像嗎？你能想像他們會做萬分、十萬分之一分錢的單子嗎？

相信我，從那之後我深深的明白，BUG的大小判斷有的時候並不能用程序員的角度來判斷。

在8bit （數據匯流排8bit, 地址匯流排16bit) 單片機上寫的一段程序，用來判斷程序升級超時，時間過長後就終止當前的升級：

中斷內：

timer中斷內每250ms調用一次

{

if (update_expire_time != 0)

update_expire_time--;

}

升級開始時初始化：

UINT8 update_expire_time = 240; //之前好好的代碼, 超時設定在60s

UINT16 update_expire_time = 360; //後來想把超時加長到90s，就改成這個樣子了，不就把數字增加一點點嘛！

主程序狀態機執行升級，並檢查是否超時：

run_update_state_machine();

if (update_expire_time == 0)

{

abort_update();

}

然後發現升級執行100s後就有很小的機率會失敗。程序已經布署到公司千多台機器上了，數量一大失敗的概率就高很多了，然後各種抱怨，說基本的升級都不測試好。

此後任何一個小小的發動我都得小心翼翼，尤其是和中斷有關的。

for（i=0;;i++）;

printf（"i love you！"）;

當年寫了幾天Ruby代碼後寫C代碼時寫了下面這個循環：

for（int i=0；i++；i&

hadoop fs -mkdir "xxx/${yyy}";

hadoop fs -rmr "xxx/${yyy}";

再次讚美hdfs的.Trash

調試數據寫的是"123"，部署的時候，忘記注釋這段了，那天，大家都死得慘，包括某訊和某浪。別問我是什麼程序。