今天在除錯打條件斷點時，想起一出除錯往事。同樣也是條件斷點，難倒了我們這所有程式設計師。為了以後總能記得這事，把這事寫到偶部落格裡。
當時我們伺服器的光哥在
linux
下用gdb
除錯一段**，發現執行到乙個地方時有乙個變數的值是乙個與預期不符的值，於是順手打了乙個條件斷點：當執行到這一行，這個變數的值為那個有問題的值時就斷下來，以確定是什麼情況下出問題。
結果，問題就來了…
跑過幾次後，光哥鬱悶的發現，這個變數的值每次都會錯，而且進一步除錯後發現，每次都是在這個條件斷點所在的行，變數的值就會突變成有問題的那個值。
反覆研究得不出結論後，光哥終於不撐了，開始拉外援。看**，查語法，查執行緒，看彙編，打資料變化斷點。最後都懷疑到硬體上了，伺服器都重啟幾次了
…全部無果。乙個又乙個的程式在光哥的這段程式前倒下了。
最後，終於有人發現問題了，條件斷點的條件語句寫錯了，本來條件應該寫：
ntableid == 864
結果手一抖，寫成了：
ntableid=864
這下好，每次執行到這個斷點時，這個變數的值就直接被改寫了，而且由於這個賦值語句的求值為非
0，於是每次還都能斷下來。關鍵最狠的是，條件斷點時把變數值修改了，你針對這個變數位址打資料變更斷點，是不會被觸發的。
結論：永遠不要把常量寫在邏輯運算子右邊。
寫成下面的樣子，絕對不會錯：
864==ntableid
這一條，不光寫**時非常有用，在條件斷點時也非常有用。這種問題從來都是一但出現，非常難查的（眼前放著
=，你也不覺得有錯的）。不要為所謂的美觀、習慣而拒絕這個寫法了，它真的能讓你的程式生涯更愉快的。
signed unsigned 引發的血案
bug描述 問題產生於區域網傳輸一幅。服務端負責傳送，是由另乙個同事用c 寫的，我用c 寫接收客戶端。我們約定在傳輸一幅前，先傳固定4個位元組的size資訊，然後傳資料。結果發現有些總是末尾壞掉一截或是乾脆就傳不過來。bug原因 在我接收到size 4 後，我採用了size size 3 256 2...
merge all引發的血案
在訓練深度神經網路的時候，我們經常會使用dropout，然而在test的時候，需要把dropout撤掉.為了應對這種問題，我們通常要建立兩個模型，讓他們共享變數。詳情.為了使用tensorboard來視覺化我們的資料，我們會經常使用summary，最終都會用乙個簡單的merge all函式來管理我們...
parseInt引發的血案
今天做了個專題活動,頁面頭上有個倒計時 專題做完後上線了,沒發現有什麼問題,結果,運營mm突然和我說 技術哥哥出問題了,360瀏覽器在秒數從10到09的時候直接變成 00 了 一看我去真的,該死的360 還有ie7 這個倒計時的原理是先獲取系統時間.分鐘,秒,毫秒賦值在span上面 span id ...