引用

Jia L, Zhong H, Wang X, et al. The symptoms, causes, and repairs of bugs inside a deep learning library[J]. Journal of Systems and Software, 2021, 177: 110935.

摘要

近年來，深度學習已經成為一個熱門研究課題。盡管它在某些場景下取得了令人難以置信的積極成果，但深度學習軟件内部的 bug 會帶來災難性的後果，特别是當軟件被用于安全關鍵應用時。在本文中，我們首次進行了實證研究，分析了一個典型的深度學習庫，即 TensorFlow 内部的 bug。基于我們的結果，我們總結了 8 個發現，并提出了我們對 4 個研究問題的答案。例如，我們發現 TensorFlow bug 的症狀和根源比其他機器學習庫（如 Mozilla）更像普通項目（如 Lucene）。再比如，我們發現大多數 TensorFlow 的 bug 存在于其接口部分（26.24%），學習算法部分（11.79%），以及跨平台編譯部分（8.02%），部署部分（7.55%）和安裝部分（4.72%）。

1.介紹

在實現深度學習應用時，程序員通常會在成熟的庫上構建我們的應用，而不是重新發明車輪。在這些庫中，TensorFlow（Abadi 等人，2016）是最受歡迎的，由于它們很受歡迎，深度學習庫内部的一個 bug 會導緻許多應用的 bug，而這種 bug 會導緻災難性的後果。

據我們所知，之前沒有任何研究對流行的深度學習庫内部的錯誤進行過探索。我們進行了第一個實證研究來分析 TensorFlow 内部的 bug。與這項工作相比，我們的擴展版本有兩個額外的貢獻。

1. 我們之前的工作（Jia 等人，2020）隻分析了 bug 的症狀和原因，但在這個擴展版本中，我們分析了 bug 的修複和多語言 bug。

2. 我們将我們确定的症狀、原因和修複模式與之前的研究進行了比較。我們發現 TensorFlow 有類型混淆，這是之前的研究沒有報告的。此外，我們發現，像深度學習應用一樣，TensorFlow 也有維度錯配。

我們的研究問題及其答案如下：RQ1. bugs 的症狀和原因是什麼？RQ2. 錯誤是如何在組件間傳播的？RQ3. TensorFlow 内部的修複模式是什麼？RQ4. 哪些 bug 涉及多種編程語言？

2.準備工作

2.1. TensorFlow 的實現

TensorFlow 使用數據流圖來定義機器學習算法的計算和狀态。在數據流圖中，每個節點代表一個單獨的數學運算符（例如，矩陣乘法），每個邊代表一個數據依賴關系。在每條邊上，一個張量（n 維數組）定義了兩個節點之間傳輸的信息的數據格式。

2.2. TensorFlow 錯誤的修複過程

通常情況下，如果用戶遇到問題（例如，bug），我們會提交一個問題，我們在本文中稱之為 bug 報告。這樣的報告提出了診斷問題的信息。錯誤報告包括基本信息和一個描述，簡要地介紹了 bug。此外，報告人可能會建議一個可行的方法來修複該錯誤。在收到 bug 報告後，TensorFlow 的開發者會讨論 bug 的可能原因以及如何修複它。

3.方法論

3.1. 數據集

我們選擇 TensorFlow 作為研究對象，應用以下步驟來提取已批準的拉取請求。

第一步。通過标簽過濾拉取請求。第二步。通過關鍵詞搜索拉取請求。第三步。提取錯誤報告和代碼修改。

總的來說，我們收集了 202 個 TensorFlow 的錯誤修複，其中 84 個有相應的錯誤報告。這個數字與其他實證研究相當。事實上，對于深度學習程序，庫通常比應用程序大得多。因此，我們分析的 bug 比之前研究的 bug 要複雜得多 s。

3.2.拉取請求和提交

核心程序員有直接提交的權力，我們把這種提交稱為直接提交。在我們的研究中，出于以下考慮，我們沒有對直接提交進行分析。

1. 拉取請求揭示了來自用戶的重要 bug。2. 一些核心程序員會以拉取請求的方式提交錯誤修複。3.拉取請求是由核心程序員審查和批準的。4. 拉取請求比直接提交包含更多的信息細節。

為了比較拉取請求中的代碼變更和直接提交中的代碼變更，我們手動識别了 104 個直接的錯誤修複。為了保證比較的全面性，我們選擇了一個叫做可維護性指數的代碼指标。為了顯示這些錯誤修複和我們數據集中的錯誤修複之間的差異，我們使用了單因素方差分析，并比較了它們的可維護性指數。我們發現，所有的差異都是不顯著的。

3.3. 手動分析

3.3.1. RQ1 的協議

對于 bug 分類，如果一個拉取請求有相應的 bug 報告，我們首先閱讀其報告以确定其症狀和根本原因。若無，我們就從拉取請求的描述、與 bug 相關的讨論、代碼修改和評論中手動識别其症狀和根本原因。在提取了所有 bug 的症狀和根本原因後，我們進一步将它們分類，并使用提升函數來衡量症狀和根本原因之間的相關性。兩個類别（A 和 B）之間的提升被定義如下。

其中 P(A)、P(B)、P(A∩B)分别是一個錯誤屬于 A 類、B 類以及 A 和 B 類的概率。如果提升值大于 1，則一個症狀與一個根本原因相關；否則，就不相關。

3.3.2. RQ2 的協議

在這個研究問題中，我們分析了 bug 的位置。作為一個開源項目，TensorFlow 并沒有正式列出它的組件，但是和其他項目一樣，TensorFlow 把它的源文件按其功能放在不同的目錄裡。在确定其功能時，我們參考了各種來源，如官方文件、TensorFlow 教程和論壇讨論。在這裡，如果一個錯誤涉及一個以上的目錄，我們對每個目錄計算一次，以确保每個位置不會失去一個症狀和一個根本原因。

3.3.3. RQ3 的協議

我們發現有些錯誤修複是重複的，即至少出現兩次，所以我們按照下一步來分析這些修複。

1. 檢查症狀和根本原因。我們檢查從前幾節中獲得的症狀、根本原因和位置信息，以勾勒出一個錯誤的總體情況。

2. 定位相關的代碼修改。我們從代碼修改中确定一個 bug 的修複規模，包括相關文件的數量、修改行數和提交頻率。

3. 分析修改的特征。重點關注 Bug 修複的幾個特征，以詳細描述修複過程。

4.提取修複模闆。我們假設具有上述類似特征的錯誤修複有可能共享同一個修複模闆。根據這些特征來定義修複模式，并提取多次出現的實例作為模闆。

3.3.4. RQ4 的協議

對于既有編程語言又有構建腳本語言的錯誤，我們檢查其症狀和根本原因，以确定它們是否包含配置錯誤和額外的缺陷。對于隻有編程語言的 bug，我們進一步檢查相關的報告和修複，以确定它們在相應文件中的修複目标，從而總結出這些 bug 的主要模式。

4. 實證結果

4.1. RQ1. 症狀和根本原因

4.1.1. 症狀的類别

1. 功能性錯誤（35.64%）。如果一個程序沒有按照設計的功能運行，我們稱之為功能錯誤。2. 崩潰（26.73%）。當一個程序不規則地退出時，就會發生崩潰。當它發生時，程序經常抛出一個錯誤信息。3. 挂起（1.49%）。當一個程序一直運行而不停止或不響應時，就會發生挂起。4. 性能下降（1.49%）。當一個程序不能在預期時間内返回結果時，就會發生性能下降。5. 構建失敗（23.76%）。編譯失敗發生在編譯過程中。6. 警告式錯誤（10.89%）。警告式錯誤意味着程序的運行不受幹擾，但仍需要修改以擺脫風險或提高代碼質量，包括要廢棄的接口、冗餘的代碼和不良的代碼風格。

4.1.2. 根本原因的類别

1. 維度不匹配（3.96%）。由張量計算和轉換中的維度不匹配引起的 bug。2. 類型混淆（12.38%）。類型混淆是由類型的不匹配引起的。3. 處理（22.28%）。由變量的錯誤賦值或初始化、變量的錯誤格式或其他與數據處理有關的錯誤使用引起的 bug。4. 版本不一緻（16.83%）。API 更改或版本更新導緻不兼容的 bug。5. 算法（2.97%）。它是由算法中的錯誤邏輯引起的 bug。6. 極端案例 (15.35%)。我們把一個錯誤歸入這個類别，由錯誤處理極端情況引起的 bug。7. 邏輯錯誤（9.90%）。錯誤發生在程序的邏輯中的 bug。8. 配置錯誤（7.43%）。由錯誤的配置引起的 bug。9. 引用類型錯誤 (4.95%)。由于缺少或添加了不必要的包含或導入語句而導緻的錯誤 bug。10. 内存（2.97%）。由不正确的内存使用引起的 bug。11. 并發性 (0.99%)。由同步問題引起的 bug。

4.1.3.分布

圖 1（a）顯示了症狀的分布。它的縱軸表示症狀類别，橫軸表示相應症狀的百分比。對于每個症狀，我們根據其根本原因細化其錯誤。圖 1(a) 顯示功能錯誤占 39%，這是 TensorFlow 最常見的錯誤。在 Mozilla、Apache 和 Linux 内核中，函數錯誤從 50% 到 70% 不等。我們發現崩潰占 26.5% 的 TensorFlow 錯誤，接近 Linux (27.2%)，挂起占 1% 的錯誤，接近 Mozilla (2.1%)。

圖 1（b）顯示了根本原因的分布。其縱軸表示原因類别，橫軸表示相應原因的百分比。對于每個根本原因，我們都會根據症狀細化其錯誤。所有症狀都有多個且分布均勻的根本原因，但根本原因的分布并不是那麼均勻。

圖 1. 錯誤症狀和根本原因的分布。

4.1.4.錯誤類别的相關性

圖 2 顯示了錯誤類别的相關性。矩形表示症狀，橢圓表示根本原因。我們忽略錯誤少于三個的類别，因為它們在統計上無關緊要（例如，挂起）。線條表示相關性，我們突出顯示值大于 1 的相關性。

我們的研究表明 TensorFlow 的崩潰與類型混淆具有相關性我們發現構建失敗與不一緻、配置和引用類型錯誤相關，警告式錯誤與不一緻、處理和類型混淆相關。我們認為其他開源項目（例如 Mozilla）也有這兩種症狀，但被忽略了。

圖 2. 症狀和根本原因之間的相關性。

4.2. RQ2. bug 定位

4.2.1.分配

圖 3 顯示了錯誤位置的分布。一些組件有更多的錯誤，因為它們的規模更大。為了減少偏差，我們将錯誤密度定義為每 1000 行代碼 (LoC) 的錯誤數。

圖 3. 不同位置的 bug 密度。

4.2.2.錯誤類别的相關性

圖 4 顯示了症狀、根本原因和錯誤位置之間的相關性。在此圖中，矩形表示根本原因；橢圓形表示症狀；圓柱體表示錯誤位置。我們忽略錯誤位置，如果它們的錯誤少于三個。線條表示相關性，我們突出顯示值大于 1 的相關性。

對于根本原因，我們發現不一緻很常見，對于症狀，崩潰和構建失敗在組件中很常見。從組件的角度來看，我們發現内核與功能錯誤和極端情況有很強的相關性，這表明語義錯誤在該組件中占主導地位。同時，我們發現 API 與與張量計算相關的根本原因具有很強的相關性。對于庫和工具，它們的症狀與構建失敗有很強的相關性，而它們的根本原因與不一緻有很強的相關性。

總之，大多數 TensorFlow 錯誤都存在于深度學習算法、API 接口和平台相關組件中。此外，它們的位置與症狀或根本原因之間的相關性遵循特定模式。

圖 4. 位置之間的相關性。

4.3. RQ3. 修複模式

4.3.1.修複模式的類别

我們發現了幾個經常性的修複模闆如下：

1. 參數修改器（21.85%）。此修複模式添加、删除或替換參數輸入。2. 方法替代者（16.81%）。此修複模式将一個方法替換為另一個參數和返回類型兼容的方法。3. 價值檢查器 (14.29%)。此修複模式檢查變量的值。4. 類型替代品 (11.76%)。此修複模式替換了變量的類型 5. 引用類型修飾符 (11.76%)。此模式添加、重新移動或替換引用的類型。6. 初始化修飾符 (6.72%)。此修複模式修改變量的初始值。7. 可變替代品（5.88%）。這種修複模式用兼容的變量替換變量。8. 格式檢查器 (5.04%)。此修複模式檢查變量的數據格式。9. 狀況替代品 (2.52%)。這種修複模式用兼容的謂詞替換了分支的謂詞。10. 異常加法器 (1.68%)。此修複模式處理異常。11. 語法修飾符 (1.68%)。此修複模式可消除語法錯誤。

4.3.2.錯誤類别的相關性

圖 5 顯示了根本原因和修複模式之間的相關性。在該圖中，矩形表示根本原因，圓角矩形表示修複模式。我們忽略修複模式，如果他們的錯誤少于三個。線條表示相關關系，我們突出顯示值大于 1 的相關性。由于并非所有錯誤修複都可以按修複模式進行分類，因此我們排除了孤立的修複。

總之，我們從我們收集的修複中找到了十個修複模闆。與之前的研究相比，我們發現了兩個新模闆，但我們發現的大多數模闆與現有模闆重疊。

圖 5. 修複模式之間的相關性。

4.4. RQ4。多語言編程

圖 6. 編程語言的分布。

圖 6 顯示了分布。我們總共發現了十個多語言錯誤，我們将它們分為兩類：

1. 總共有 6 個 bug 是配置 bug。

2.另外四個 bug 修改了其他語言的測試用例。

綜上所述，我們發現隻有 10 個 TensorFlow bug 涉及多種語言。

4.5.有效性的威脅

有效性的内部威脅包括我們人工檢查可能出現的錯誤。為了減少威脅，我們請兩名學生檢查我們的錯誤。當他們遇到有争議的案件時，我們在小組會議上讨論，直到我們達成一緻。可以通過更多的研究人員來減輕威脅，因此我們在我們的網站上發布了我們的檢查結果。外部有效性的威脅包括我們的主題，因為我們隻分析了 TensorFlow 的錯誤。盡管我們分析的錯誤與之前的研究和其他研究（例如 Zhang et al. (2018)）相似，但也僅分析了 TensorFlow 錯誤，但它們是有限的。可以通過檢查更多錯誤來減少此線程。

5. 結論

雖然研究人員已經進行了實證研究來了解深度學習的 bug，但這些研究主要集中在其應用的 bug 上，而深度庫裡面的 bug 的性質在很大程度上還是未知的。為了加深對這種 bug 的理解，我們分析了 TensorFlow 内部的 202 個 bug。我們的結果表明：（1）它的根本原因比它的症狀更具有決定性；（2）傳統軟件和 TensorFlow 中的 bug 有各種共同的特點；（3）不适當的數據格式（維度和類型）是容易出現 bug 的，在 API 實現中很流行，而不一緻的 bug 在其他支持組件中很常見。

鳴謝

本文由南京大學軟件學院 2021 級碩士林聚翻譯轉述。