不知道哪一次更新，也不知道因為更新了什么，PC 上的 IGV 突然就不能用了。除了換一臺 Mac 以外還能怎么辦。下文記錄了 debug 的過程以及一點思考。

前奏

IGV 這個工具因為是 Java 全平臺適配的，一般不太容易出現(xiàn) bug。在 Windows 上常見的問題是由于 Java 32位和64位版本問題造成的。在 64 位的電腦上安裝了 32 位的 Java（通常默認(rèn)就是32位）后，如果給 IGV 分配的內(nèi)存超過了 2G，就會報內(nèi)存錯誤，直接體現(xiàn)為 igb.bat 點擊后無法打開。最直接的方法就是把 Java 升級到64位。

然而，不知道是哪一次更新，不知道是因為更新了什么，我的 bug 表現(xiàn)是 IGV 可以正常啟動但啟動后只要進(jìn)行任意的一次點擊就會閃退。最初我的猜測是因為某一個內(nèi)容的更新，導(dǎo)致了Java，Windows 和 IGV 三者不兼容。于是我分別更新了最新版的 IGV 和最新版的 Java，然后還升級過一次電腦系統(tǒng)，問題都沒有得到解決。當(dāng)時時間有限，debug 的最直接方式就是繞開 bug。

替代方案

必須要用的軟件突然不能用了又急著用，立刻買個 Mac 就可以避免 Windows 上的問題，雖然錢不是問題，但問題是沒錢，所以只能尋找其它替代方案。因為 Java 本身是全平臺通用的，所以在服務(wù)器上下載了 IGV linux 版本，然后通過 Xming 在本地電腦上調(diào)用 Linux 開啟的 IGV 圖形操作界面。

這個方法解決了燃眉之急，但是從服務(wù)器通過 Xming 在本地進(jìn)行點選，很多操作會用明顯的卡頓和延遲而且分辨率很低。并非長久之計。

dubug 過程

首先需要看一下相關(guān) IGV 報錯信息

閱讀報錯信息

因為我本身不懂 Java，只能根據(jù)報錯提取自己認(rèn)為關(guān)鍵的內(nèi)容進(jìn)行檢索。

從以往的經(jīng)驗來看，首先要重點關(guān)注哪里失敗或者不能啟動。在 log 文件 header 部分恰好出現(xiàn)了一句話「Failed to write core dump. Minidumps are not enabled by default on client versions of Windows」，這個信息看起來非常關(guān)鍵，很可能是因為 Windows 不可以寫入 core dump 導(dǎo)致的問題，那么自然應(yīng)該首先開啟 core dump 試試。

在 SO 上查到了 core dump 的開啟方式，對于Java 8 使用 -XX:+CreateMinidumpOnCrash 參數(shù)即可。修改 igv.bat 文件再命令行里添加該參數(shù)后重新運行，問題依舊存在，只不過這次除了會生成 log 文件以外，還會生成一個大小幾 G 的 core dump 文件。看來這個問題并不是 IGV 閃退的原因。

在檢索的過程中，有中文帖記錄出現(xiàn)這樣的問題是因為「JRE version 和 JDK 不一樣」。所以重新下載一個版本對應(yīng)的 JDK 或者 JRE 就可以解決。雖然我一開始其實也分不清他來有什么區(qū)別，也不確定自己是不是同時裝了這兩個東西，但是抱著試試又不會掛的心態(tài)，還是再一次卸載了電腦里的Java。

因為擔(dān)心是之前 Java 升級有問題，我還專門下載了官方的Java 卸載工具，想把自己電腦里所有和 Java 相關(guān)的東西都卸載個干干凈凈，重新來過。

按照 IGV 網(wǎng)站上給的 Java 8 下載鏈接，我又一次重新安裝了 Java，運行之后真的還沒有出現(xiàn)閃退的情況，因為根本就打不開了。其實這就是上文提到的因為 IGV 網(wǎng)站上的 Java 下載鏈接引導(dǎo)我下載了 32 位 Java 版本，但是 IGV.bat 中使用的內(nèi)存配置是4G，超過了限額地緣故。我又不得不再一次卸載 32 位重新安裝了 64 位Java，閃退問題依舊存在。

不過，至此我確認(rèn)了電腦不存在所謂的「JRE和JDK版本不一致的問題」，版本信息如下：

控制變量

Debug 一個非常重要的經(jīng)驗是需要 控制變量。如果有條件，不妨找一臺能夠正確運行某個程序的機(jī)器，看看它和自己報錯的機(jī)器有什么差別。

為此，我分別查看其他人幾臺可以正確運行 IGV 的 PC，發(fā)現(xiàn)有人的IGV版本較低，有人的 Java 版本較低，但是大家都可以正常使用，于是我又分別測試了幾個低版本的 Java 或者 IGV，然并卵?？紤]自己的筆記本系統(tǒng)和軟件版本與我的工作 PC 高度一致，又用最新版的 IGV 和 Java 8 在筆記本上進(jìn)行了測試，神奇的是在筆記本卻可以正常運行。

至此，我基本懵逼。因為Windows 系統(tǒng)和 IGV 版本以及 Java 版本完全一致的情況下，筆記本可以正常運行IGV，但是 PC 卻不可以。這里面一定有某些不可告人的力量。

理解報錯信息

通過上面幾步折騰，問題的關(guān)鍵應(yīng)該不在于解決 「Failed to write core dump」而是需要再向前回溯，這個時候就要理解 Java 生成的log文件究竟傳達(dá)了哪些信息。

通常只有嚴(yán)重的錯誤引起Java進(jìn)程非正常退出，出現(xiàn)了Crash，才會產(chǎn)生一個文件名為err+pid number 的日志文件。

檢索后發(fā)現(xiàn)很多 Java 的報錯都會出現(xiàn) EXCEPTION_ACCESS_VIOLATION(0xc0000005)這一句話，他意味著Java 應(yīng)用 Crash 時正在運行 JVM 自己的代碼，而不是外部的 Java 代碼。在這個位置還可能出現(xiàn) SIGSEGV(0xb)或者 EXCEPTION_STACK_OVERFLOW這樣的內(nèi)容。

再往下看另一個重要信息點是

這里的信息是顯示 Crash 時 JVM 正在從哪個庫文件執(zhí)行代碼。我遇到問題是 C，還可能是 V 和 J 等等。他們的意思如下

接下來我又閱讀了一下 Java 的 debug 指南，里面的分析思路都是要看 C 后面提示了什么信息，然后給了一些 debug 的建議：

The first step to solving a crash in a native library is to investigate the source of the native library where the crash occurred.

• If the native library is provided by your application, then investigate the source code of your native library. A significant number of issues with JNI code can be identified by running the application with the -Xcheck:jni option added to the command line. See The -Xcheck:jni Option.

• If the native library has been provided by another vendor and is used by your application, then file a bug report against this third-party application and provide the fatal error log information.

• If the native library where the crash occurred is part of the Java Runtime Environment (JRE) (for example awt.dll, net.dll, and so forth), then it is possible that you have encountered a library or API bug. If so, gather as much data as possible and submit a bug or report, indicating the library name. You can find JRE libraries in the jre/lib or jre/bin directories of the JRE distribution. See Submit a Bug Report.

仔細(xì)閱讀之后發(fā)現(xiàn)基本沒讀出啥東西，但是現(xiàn)在從報錯信息中我已經(jīng)明確了問題應(yīng)該指向 atig6pxx.dll。

指果所因

既然定位到了atig6pxx.dll ，就要查查它是什么，搜索 atig6pxx.dll windows10在前面幾條結(jié)果中，我看到了這樣幾個信息

1. AMD Graphics Driver not working/incompatible with Win 10 Technical Preview

2. OpenGl for crimson drivers

如此看來，這個 atig6pxx.dll 和AMD 的顯卡驅(qū)動有關(guān)，而我的兩個顯示器之一顯卡確實是AMD的，從查詢結(jié)果來看，AMD 顯卡驅(qū)動的這個 atig6pxx.dll 和某些 win10 版本搭配在一起就存在問題（我用的就是有問題的版本？）。

接下來再試試 atig6pxx.dllJava的搜索結(jié)果，真還搜到了相關(guān)的一個帖子，官方給的回復(fù)大意是要發(fā)帖子的人詳細(xì)確定顯卡和升級之類的各種信息，看來這個問題確實是 Java 和 PC 的顯卡驅(qū)動有 bug。同時又聯(lián)想到我的控制變量實驗，筆記本是NVIDIA顯卡而不是AMD，進(jìn)一步相信問題可能真出自 AMD 顯卡上。

解決問題

確定了bug的原因，接下來就要考慮如何解決問題。

首先需要知道 Java 和顯卡驅(qū)動是怎么能聯(lián)系到一起的，檢索一下 Javagraphics找到了 官網(wǎng)的一些說明。 這里主要涉及 Java 2D 這么一個東西，在搜索的過程中又找到了 Java 2D 的一些選項。在檢索的過程中，還從 SO 看到了一個稍微相關(guān)的帖子，其中一個建議也是對顯卡進(jìn)行一系列的測試，其中提到了參數(shù) -Dsun.Java2d.d3d=false。這里的參數(shù)和Java 2D 的參數(shù)吻合而且有一點眼熟，看到這里就要回過頭重新看看 igv.bat 文件。

官方提供的 igv.bat 實際命令如下

仔細(xì)看一下，官方這條命令實際調(diào)用的程序來自 lib 目錄的 igv.jar，只不過添加了幾個平時自己根本不會在意的參數(shù)，其中 -Dsun.Java2d.noddraw=true和之前 SO 中建議添加的參數(shù)非常類似，而這個參數(shù)又是一個和顯示性能相關(guān)的參數(shù)。隱約感覺問題就出在這里。

繼續(xù)貫徹控制變量的思想，首先不加任何參數(shù)在 lib 目錄下直接運行 igv.jar，嗯，真的沒有閃退?；氐?bat 依次修改上面三個參數(shù)進(jìn)行測試，直到我把 -Dsun.Java2d.noddraw=true 改為 false 后，bug 消失，至此問題解決。

復(fù)盤與反思

綜上，通過學(xué)習(xí) log 文件，查找關(guān)鍵內(nèi)容，控制變量測試，一步一步把 Java 的運行錯誤和顯卡聯(lián)系起來。不過我是萬萬沒想到這錯誤竟然是和顯卡相關(guān)。

進(jìn)一步了解下Dsun.Java2d.noddraw這個參數(shù)的作用

The following list describes some useful properties on Windows platforms.

• The DirectDraw/GDI pipeline is the default pipeline for Windows. Change this default as follows:

• -Dsun.Java2d.noddraw=true Disable the use of DirectDraw pipeline. GDI will be used instead.

• -Dsun.Java2d.noddraw=false Enable the use of DirectDraw pipeline.

• -Dsun.Java2d.d3d=false Disable the use of Direct3D pipeline.

也就是說，因為AMD 顯卡驅(qū)動中 atig6pxx.dll的問題，我目前的電腦并不能只使用 GDI 來進(jìn)行渲染，而是必須要開啟 DirectDraw。至于更深次的原因暫時沒有深究的必要。

回顧整個 debug 的過程，雖然一直在嘗試使用控制變量的思路，但是具體的測試順序不對。

使用別人的電腦來控制變量，不相關(guān)的因素太多，各種軟件版本的不一致只是表象，并沒有指明到是真正的顯卡差別；而使用自己的筆記本和臺式機(jī)做比較，才排除了軟件版本的關(guān)系。

最后進(jìn)行的控測試才是變量最可控的，應(yīng)該首先就進(jìn)行的在同一個電腦上對同樣的軟件進(jìn)行不同的操作。其中一個操作是官方并不推薦的直接運行 lib 中的 igv.jar 程序，另一個操作是運行官方推薦的添加了參數(shù)的 igv.bat 。如果把這個測試提到第一步來做，就會節(jié)省大量的測試時間。

最后，對于 debug 的思考：

• 
  

  仔細(xì)閱讀報錯信息確定關(guān)鍵詞

  成熟的工具一定有著非常詳細(xì)的報錯信息，而我們要做的是從詳細(xì)的報錯信息中提煉關(guān)鍵詞進(jìn)行檢索

  
  

• 
  

  按照從小到大的順序盡量找到可以正確運行的方式

  想要找到問題所在很關(guān)鍵的一點知道誰或者在哪里可以成功。這一步對之后的 debug 過程十分重要。

  所謂從小到大的意思是正確運行和錯誤運行之間的差異從小到大。最好可以在一臺電腦上完成，只是改變運行方式或者參數(shù)；如果不行就找配置盡量類似的電腦或服務(wù)器進(jìn)行測試，以此類推。如果我首先能想到拋棄官方的建議打開方式去運行 jar 程序，直接就可以鎖定參數(shù)問題。

  
  

• 
  

  控制變量是進(jìn)行測試應(yīng)該遵循的首要思路

  通過檢索，我們可以找到大量的相關(guān)信息，可能會存在各種五花八門的解決方法。如何判斷哪些值得嘗試哪些不值得嘗試非常重要。對于本文的 bug，即便檢索到了很多關(guān)于軟件版本的問題，只要我在版本相同的另一臺電腦運行成功，那么所有和 Java 版本，Windows 版本以及 IGV 版本相關(guān)的內(nèi)容都可以忽略掉，就省去了多次卸載安裝這樣的無用功。同時根據(jù)檢索信息再結(jié)合控制變量的思想就更加容易鎖定問題，進(jìn)而找到解決方式。