原創文章，轉載請註明出處：http://blog.csdn.net/wind5shy/article/details/6546303
今天在調試代碼時遇到了因爲斷點設置而被誤導,錯誤判斷拋出異常的代碼位置的情況,非常有迷惑性,一度百思不得其解,差點就讓帥哥我拿豆腐撞死了!O(∩_∩)O~具體如下:
if (req == ptr_t.NULL) {
req = lock_head_t.find_lock_request(lock, the_xlinfo);
if (l.isDebugEnabled()) {
if (req != ptr_t.NULL) {
SM.DBGTHRD(" request=" + lock_request_t.toString(req));
} else {
SM.DBGTHRD(" STILL NO REQUEST");
}
}
}
/** do the task */
boolean success = false;
boolean has_waiter = false;
while (true) {
/**
* See if this is a conversion request
*/
if (req != ptr_t.NULL) {
在開始的if和後面的while處設置了斷點,F8運行,在進入whlie斷點前,報如下錯誤:
java.lang.Error
at com.hw.ogsa.util.Ensure.isLegal(Ensure.java:37)
at com.hw.tartarus.os.core.KERNEL.undefine(KERNEL.java:361)
at com.hw.tartarus.sm.store.test_create_file.main_run(test_create_file.java:66)
at com.hw.tartarus.os.core.sthread_t.run(sthread_t.java:1134)
at java.lang.Thread.run(Unknown Source)
com.hw.tartarus.os.error.StoreException: E_INTRANSin active transaction (not allowed for this operation)
at com.hw.tartarus.sm.core.smthread_t.join(smthread_t.java:352)
at com.hw.tartarus.sm.store.test_create_file.main(test_create_file.java:84)
根據一般經驗,覺得應該是do the task之前代碼有問題,於是F6單步調試,又沒有問題!
於是懷疑是代碼中可能涉及了鎖操作,而且應該和線程相關(因爲第二個異常的信息).
仔細研究了第二個異常的信息,發現這是主線程在測試線程異常結束後進行相應的處理時拋出的異常,也就是說和代碼的異常和線程沒有什麼關係.
再仔細研究了代碼,代碼涉及鎖的只有一處,而且F8可以運行過,這麼看來鎖也沒有問題.
於是再F6,還是沒有問題...F8,還是報錯...囧
再一次F6時運行過while時突然發現光標在whlie這行代碼似乎直接跳過去了,於是在while前後的代碼分別下了斷點,F8,果然,while處的斷點直接就跳過去了,也就是說報錯的代碼不在while前,而是在whlie後!杯具!
仔細研究了下,if(true),for(;;)這些語句也是一樣的情況,不過如果是循環(for,while),第一次是直接跳過,但以後就會進入語句;而do{}while(true)則每次都會進入.估計這個可能是jvm做的優化造成的.