利用視圖工具查找嵌入式系統的軟件問題

軟件視圖工具通過記錄在多處理程序執行過程中交互作用的細節，使得程序員可重放有問題的程序段，來發現傳統的診斷工具難以發現的軟件設計問題。本文從六個事例入手，說明利用視圖工具查找嵌入式系統的軟件設計問題的好處。

實時嵌入系統的商用系統行為視圖工具主要用來查找那些以通常的“查找斷點和分析斷點”的調試難以發現的問題，這些工具對于查找“Heisenberg 問題”尤其奏效，因為當我們運用普通工具開始查找時，這樣的問題難以發現。

記錄工具較之于其它的調試工具對系統的影響較小，因其不太可能嚴重擾亂系統以至于難以查找問題，但這一記錄工具會凍結在記錄文件中的錯誤記錄,并在以后空閑時間對其進行檢查。你可以指定一個用于記錄組件的觸發點，這一觸發點也許是一個總線故障或者是某些系統服務的第N次故障。記錄后臺程序會截取觸發事件附近的事件的記錄，并將它們傳送到將其形成圖形以便分析的工具中去。

運用視圖工具的正常周期是從某一問題開始的，假設系統被凍結，標準的調試實用程序就會顯示出兩個任務沒有任何運行，它們最后的行為都是等待鎖死。但是，如果存在問題，代碼檢查就會顯示兩個任務都在等待鎖死，只是等待的時間不同。實際上，該設計要專門調用那兩個任務，將這個鎖死在兩個任務之間來回傳遞，視圖工具就是利用這個javascript:;" onClick="javascript:tagshow(event, '%B9%A4%D7%F7');" target="_self">工作原理來發現軟件設計錯誤的。

視圖周期在微調觸發點指標和檢查記錄之間反復，直至問題很清晰地出現在視圖中并有充分的行為來表明問題的根本原因。在這個例子當中，視圖周期顯示某一任務想盡力在某一程序段內獲得兩次死鎖，同時不允許其它任務運行。這時，程序員就能夠找到問題所在。

幾年前我設計了一種叫做HawkEye的視圖工具，其主要兩種用途是：(1) 查找在兩個任務間的通信過程中由競爭條件所造成的問題；(2) 在短時間間隔上，調整性能。

當我設計Hawkeye的時候，腦海中就浮現出了即時重放的圖，這一點也得益于同惠普(HP)邏輯分析儀共事數百個小時得出的靈感。大體上講，Hawkeye是一個邏輯分析軟件。你選擇某一個觸發點并開始運行它，當觸發點事件出現時，Hawkeye會給出一個包含觸發點附近信息的時線圖。你選擇這個觸發點，所以線徑包含有問題的時間間隔或需要進行優化的時間段。Hawkeye將它所收集的數據以圖形表示出來，并使競爭條件和性能問題易于觀察。

基于Hawkeye測試版完成測試的基礎上，我們決定收集幾個實例，目的是進一步完善Hawkeye。

事例1

我曾記錄了用以測量上下軟件間的切換時間的基準程序，但它在完成幾次上下軟件間切換后會閉鎖起來。分析表明：系統調用本來只需要幾毫秒，實際上卻花了幾秒時間?；鶞食绦蛟谒鼏雍蟛痪镁蜁梨i，因此我選擇基準程序起始分支來觸發。

如圖1所示，黃線表示正在等待旗語的線，淺黃色的箭頭表示未鎖的系統調用，黃色的三角形表示鎖死的系統調用，黑邊框線的圖標表示進入系統調用，淡色邊框線的圖標表示從系統呼叫中退出。在屏幕中間有正在鎖死某個旗語并等待的線程11和線程12，這即是死鎖現象，從在死鎖的線程12的左邊你可看到原因。有某一個釋放線程11的未鎖系統(見交互作用線)，然后線程12再次釋放旗語。

釋放二進制旗語兩次與釋放一次無異。不知何故，我想到當線程12釋放鎖的時候，線程11會立刻醒來，并且直到線程11已醒來并重鎖旗語，第二個未鎖系統調用才會發生?；蛟S這些在線程12的未鎖系統間的紫色的圖標(表示一套優先系統調用)尚可資研究。我沒有記錄排除這些死鎖的過程，但我做到了?；鶞食绦颥F在運行很正常。

這是視圖工具設計的目的所在，我知道存在某個與系統的多組件的交互作用相關的問題，該工具給出了問題附近的系統行為的抓取記錄，這些記錄使我找到了問題所在。

事例2

John正在測試一個作為銷售工具的產品機頂盒。它不會運行圖形Java，如Java無圖運行,它會運行得更好，而且不會因腳本或環境變化的干擾而致Java打開一個視窗。用在機頂盒上的軟件運行很好，John添加上去的軟件在其它平臺上也同樣運行良好，但當把該軟件與機頂盒混合在一起的時候，似乎就出問題了。

John是一個很好的技師，但不是一個好的程序員，但即使是一個好的程序員也會遇到困難。機頂盒中的大部分軟件已在工廠中由閃存固化而完成的，因而找不到符號調試所需的信息。John找到的線索是：應當運行window管理器的某個步驟不正常，盡管看起來這個步驟好像啟動了，但實際并沒有。他將記錄后臺程序添加到系統中并啟動了它們。在與程序員一起檢查后，他把觸發點設置在記錄中間某個特殊系統調用的第一個位置。

問題恰好就在觸發點之前。某個低位圖形組件正在調用來自圖形驅動器的某個服務，該請求返回一個未知服務錯誤。幾微秒之后，那一過程在指令存取上顯示存儲錯誤，因而被操作系統終止。問題存在于兩點：調用服務的組件應當檢查回歸碼，同時驅動器也應當支持這一服務。John把這個記錄文件帶給了程序員，程序員立刻查明并解決了這一問題。

在此，關鍵的問題是John不是程序員，某個系統完成的圖形視圖將問題報告由“我不能使Java 與圖形一起運行，”改為“在這個圖形服務實施過程中或應用方式上存在錯誤?！?

事例3

某一系統運行正確但執行速度很慢，仿佛CPU的負擔很重，但問題診斷不出來。性能良好，系統正常的情況下，造成CPU負擔太重的原因很多。

后來，更多的軟件被添加到系統中，程序員隨意查看和播放。我記錄了某個測試程序執行時的某個鏡頭，看著這個鏡頭，我的注意力被一個特殊的記錄過程所吸引。由于記錄程序正在監視的裝置沒有運行，記錄器應當在某個事件等待被屏蔽，但顯示器顯示正忙。它正在用盡每個可用的CPU周期以便盡可能快的完成事件等待系統調用。所有這些事件等待系統調用均立即返回。它們都在等待同一個事件，而且它們均來自于同一個地址。這個記錄程序應當在測試程序的整個執行期間只等待一個事件等待調用，很明顯其中存在一些錯誤。

很快，發現是事件配置不正確。在某一事件等待被返回后，后續的事件等待要無屏蔽地返回。幸虧(或許是不幸)程序進行了檢查，以查看它所等待的事件是否發生；如果沒有發生，它是否會繼續等待。程序員修改了事件配置后，系統的運行速度大大地加快了。

這個錯誤或許從未被發現過。它不會導致某個軟件不適配，也不會產生不正確的結果，或使系統鎖死。系統即使通過了它的測試組，但是，只有用視圖工具來查看系統，問題才變得一目了然。

事例4

這兒舉另外一個不會造成明顯故障或性能問題的事例。系統看起來是正常的，但當程序員運行某個視圖線跡來查看它是什么問題的時候，線跡表明存在若干非同尋常量的未鎖運行，它們當中大部分以緊密組出現，除了第一個返回一個錯誤信息外，總共有10個快速進行的未鎖系統調用。

原因是由于將多用戶計算機操作系統(UNIX)接入這一程序的人員沒有注意到：他在使用了計數旗語的原程序上使用了二進制旗語。如果在一段程序當中幾次出現未鎖系統調用，二進制旗語不會有任何釋放。程序與二進制旗語一起運行，但是旗語正在管理的隊列決不會僅由一個入口填滿。系統上下軟件之間切換過頻，達到大約10次，但仍在性能要求范圍內，當二進制旗語被某個計數旗語代替時，系統運行更為良好(至少看起來如此)。

事例5

HawkEye線跡含有我正在尋找的問題的完好信息，而且完全朝向線跡未端，像一個蹩腳楔子，圖2將這個楔子放大，我發現它是由均在同一個事件上的約一百個左右的事件設置系統調用組成的，盡管這些事件設置組合釋放了一個事件等待。麻煩的是這個事件設置系統調用中的某一個可能足以釋放等待任務。這發生于一個到偽-TTY裝置的寫調用的底部(遠程登陸對話應用這些來實現類似終端的槽連接)。這個偽-TTY的終端部分正應用事件來控制裝置插槽端的數據搬移，它為每一個特征設置事件，因此，我確信我已經找到了問題所在。

雖然這個線跡顯示了問題所在，但實際情況卻不是。它是一種相對簡單的界面的圖形描述，這一界面位于某一個特征裝置和某一個數據包裝置之間。通過讓每一特征上的操作系統上下文切換，通信速度可減慢到約300bps，從而確定問題所在。以每一線而非每一個特征來設置事件聽起來不失為一個好主意，但偽-TTY并非以線為導向，一次發送一條線就會像全屏編輯器那樣中斷程序。

有時候正確的實現方案看起來卻很別扭。

經驗教訓

上述事例表明：視圖工具能夠發現在完全調試過的軟件當中所存在的許多問題。當它專用于查找特殊故障的原因時，它從不會出錯，此外，它似乎也能夠發現像程序員正在尋找的問題。后兩類在我們的記錄文件中占主要部分。程序員遇到的問題能夠全部由軟件的單步運行或通過使程序中斷來徹底來加以查明。它們不是視圖工具要解決的具有奇怪競爭條件的問題，這些問題的發現是由于視圖工具使其更加容易地搜集在系統執行過程中的數據，從而使工程師能夠利用大腦的圖形檢測能力對問題進行分析。

我很想知道，上述事例是否代表了嵌入式領域以外的問題。也許我一直在緊張的CPU和存儲器預算中工作的太久，以至于喪失了自己的看法，在此，大部分意外事例都同僅遭受性能問題的系統有關。此類例子還很多，例如：
1. 某個程序會一個接一個的分配成打的小的存儲塊，此后這些存儲塊將按序釋放出來。沒有理由說明對所有這些結構，這個程序不會分配某一個鄰近的存儲塊。
2. 某個程序一遍遍分配并立即釋放某個存儲塊，但是它應當只分配和釋放一次。
3. 某個程序多次打開并關閉文件。
4. 另一個程序多次打開某個文件卻未關閉它。
5. 某個程序反復對信號掩碼，然后以相同的次數去掉信號的掩碼。
6. 某個程序嘗試返回某個未知服務錯誤的系統調用，并立即再次嘗試調用。

上述行為在桌面或主機軟件中是可接受的嗎？對于嵌入式實時程序員而言，或許視圖工具比其它程序員有價值得多。

我一直在設計和使用視圖工具，好像他們是軟件的邏輯分析儀。這一工具收集并顯示圍繞某一特定問題執行時的細節。這是一個重要的應用，但工具也顯示了在軟件執行時的高級圖形模式。用戶的事例告訴我們：程序員應當用每一種可用的工具來檢查他們的產品，而且我們還需要更多和更好的工具來觀察軟件的運行情況。

我期望用戶的事例將揭示：HawkEye需要收集和顯示更多的資料，而且它還需要更復雜的觸發點。我明白這一點，但是，我不會采取與我的用戶相同的方式。他們正應用HawkEye作為觀察軟件黑盒子內部最為簡便的手段，可以自豪地說，HawkEye在查找問題的過程中正在發揮作用。

作者：Peter Dibble
TimeSys公司
Email: pter@speakeasy.net