今天加班在給new guys做培訓的時候，發生了乙個莫名其妙的問題，幾經周折，才發現是公司現有框架的乙個bug。
xml **
<
converter
>
<
valueobject
objectid="lib"
class="com.icsc.tm.mscdao.tmjcs03vo"
type="unique"
/>
converter
>
正如xml中所描述的一樣，框架應該保證在任何情況下都應該用乙個com.icsc.tm.mscdao.tmjcs03vo物件去封裝結果，但今天所發現的乙個問題卻是因為框架返回了乙個莫名其妙的arraylist造成的。在不同條件下我進一步確認了這個bug。
本來這件事也沒什麼好說的，程式有bug就跟天要下雨娘要嫁人一樣，實非人力所能為。但聯想到公司的現狀，卻也著實讓人沒了心情。想起當初那些在夢裡都還想著程式的日子，想起一堆人拿著個滿是殘影的投影儀在一間堆滿雜物的小房間大吵大鬧的日子，幾乎仿如隔世，誰還記得那也不過是1年前的日子啊。
走人看來是遲早的事了。只是眼看著自己曾經為之努力，還戲言要「呆上10年的」的公司，如今卻上下不達，人心浮動，箇中滋味實難以名狀。舊人已去，新人還來，只不知，新人何時竟已成舊人？
乙個由有符號下標引起的bug
先看段 if s d i 這裡的d是乙個char 的記憶體buffer，s是乙個256長度的bool陣列。上段 邏輯是，s已進行過初始化，其作用是過濾位元組，有些位元組對應true，有些位元組對應false。明顯，d i 有256種可能。上面的邏輯正確麼？上面的 其實就是我專案裡的一段 看似沒有問題...
處理系統中乙個併發引起的bug
之前系統在更新某條業務資料的狀態時，並沒有判斷該資料的原來的狀態，直接更新成了最新狀態。這樣如果有多執行緒來訪問 會出現由於併發導致出現髒資料。idname status1測試 1當某個業務請求過來後，我們會把訂單資料的status更新成2，表示訂單完成，然後進行後續業務動作，產生一些正常的業務資料...
memcpy引起的乙個bug
void memcpy void dest,const void src,size t n 由src指向位址為起始位址的連續n個位元組的資料複製到以dest指向位址為起始位址的空間內。memcpy dest,0,5 真正應該使用的是 memset dest,0,5 關於memset memset 函...