一種面向枚舉類型的配置約束提取方法*

曾廣福,何浩辰,周書林

(國防科技大學計算機學院,湖南 長沙 410073)

1 引言

當今隨著計算機技術(shù)的迅速發(fā)展和計算能力持續(xù)提高，計算機軟件系統(tǒng)也隨之不斷發(fā)展。在軟件規(guī)模方面，目前常用的開源軟件規(guī)模均已達到了百萬行量級。據(jù) Coverity公司[1]的年度開源軟件代碼分析報告顯示，目前 Linux 內(nèi)核源碼規(guī)模正在以接近每年百萬行量級的速度增長。

由于軟件規(guī)模的不斷擴大和軟件可配置性的不斷增強，軟件系統(tǒng)的配置項數(shù)量顯著增加，從而使用戶使用軟件系統(tǒng)時產(chǎn)生配置故障的幾率顯著升高。目前，軟件配置故障已經(jīng)成為系統(tǒng)異常、服務失效甚至系統(tǒng)崩潰的重要原因之一。Barroso等人[2,3]的報告稱在谷歌的主要服務中，配置故障是導致服務失效的第2大原因，僅次于軟件本身故障，占到了近 29% 的比例。

目前，軟件配置項數(shù)量巨大，且系統(tǒng)中配置項均需要滿足特定的配置約束，由于用戶缺乏軟件相關(guān)的領(lǐng)域知識，進行軟件配置時極易違反對應配置約束而導致配置故障。目前軟件用戶和開發(fā)者常用的配置故障診斷方式是通過尋找配置需要滿足的約束條件來定位出錯的配置項。但是，上述配置約束條件的提取難點較多，如配置項之間或配置項與系統(tǒng)運行時環(huán)境之間存在復雜的配置關(guān)聯(lián)約束關(guān)系，需要綜合考慮源代碼和系統(tǒng)運行環(huán)境。綜合上述挑戰(zhàn)，需要實現(xiàn)自動化的方法完成軟件配置項的約束提取。

針對上述現(xiàn)狀，本文首先對6款常用開源C/C++軟件源碼進行分析，提取了對應的配置相關(guān)特征。枚舉類型配置作為軟件系統(tǒng)的常用配置類型，其取值空間經(jīng)常為固定的少數(shù)幾個字符串或整型值，用戶在不了解的情況下很容易錯誤設(shè)置對應的枚舉配置值，導致配置失敗或引發(fā)配置故障。另一方面，枚舉類型配置在代碼中通常存在普遍的代碼分析段，具有一定的普遍特征，因此針對枚舉類型的配置項取值空間進行提取很有必要。

2 相關(guān)工作

陳偉等人[4]總結(jié)了配置相關(guān)的研究，并提出導致軟件配置錯誤的主要原因之一是軟件組件依賴導致的配置依賴。配置依賴存在單個配置依賴和配置間的依賴，本文所研究的配置約束屬于單配置依賴范疇。

清華大學的李福亮等人[5]首先對互聯(lián)網(wǎng)自動配置及配置案例進行概述；然后按照配置自動生成、配置驗證、配置自動實現(xiàn)這3個方面對互聯(lián)網(wǎng)自動配置研究進行分類總結(jié)和分析評價；最后總結(jié)了當前研究中存在的問題，其中配置約束的提取是提升當前相關(guān)工作的重要基礎(chǔ)。

現(xiàn)有的關(guān)于配置約束的研究工作主要包括SPEX[6]和EnCore[7]。SPEX首先需要識別源代碼中的配置變量，然后用程序分析手段跟蹤數(shù)據(jù)流的每個程序變量與對應的配置參數(shù)，并記錄所有數(shù)據(jù)流路徑中發(fā)現(xiàn)的配置約束。EnCore則從配置數(shù)據(jù)集的角度，基于預定義的約束模板，分析可能存在的約束。

但是，上述研究工作均存在對應缺陷。SPEX可以基于正則表達式和簡單語義判斷推斷出配置項簡單的語法約束，包括是否符合基本數(shù)據(jù)類型等，但無法分析出配置項上下文語境或其本身語義所產(chǎn)生的約束，沒有對枚舉型配置項需要滿足的約束進行系統(tǒng)的分析和提取，且成功率較低。EnCore方法則由于沒有源碼的支持，僅通過人工定義，從數(shù)據(jù)分析角度提取約束，模板的發(fā)現(xiàn)是不完備的。另外，SPEX和EnCore只關(guān)注Switch-case-statement型的代碼段提取枚舉配置約束的情況，然而通過調(diào)研發(fā)現(xiàn)，Switch-case-statement模式在本文調(diào)研的開源軟件中并不常見。

本文研究發(fā)現(xiàn)，枚舉類型配置項(與枚舉約束一一對應)在開源軟件中大量存在，如表1所示；不同類型的配置項(分類同文獻[6]，見表 2 )帶有不同比例的約束。而其中枚舉類型全部天然地帶有約束，而前人工作對此研究十分簡單。

Table 1 Numbers of constraints of enumeration-type configurations in some open source softwares表1 若干開源軟件中枚舉類型約束總數(shù)

3 設(shè)計和實現(xiàn)

開源軟件的配置約束具有一定的規(guī)律性，本文所提出和實現(xiàn)的面向枚舉類型的配置約束提取技術(shù)即基于此特性。

Table 2 Constraints ratio of restriction for different data types表2 不同數(shù)據(jù)類型存在約束的比例情況 %

3.1 開源軟件中枚舉類型配置源碼特征分析

軟件配置的功能主要是作為軟件系統(tǒng)功能的調(diào)節(jié)器，是軟件系統(tǒng)中的一種常量。因此，從設(shè)計意圖上來說，一般配置變量在程序中均應為直接使用，不涉及數(shù)據(jù)流賦值傳播的情況(即將配置賦值給其他變量，再通過被賦值的其他變量進行程序控制)。在本文所調(diào)研的開源軟件中，絕大部分枚舉類型的配置項在源代碼中是直接被使用，沒有經(jīng)過二次賦值。并且，枚舉型配置變量的取值大多為宏定義類型或者C++中的枚舉類型，這樣可以很直接地獲取配置變量的取值。

另外，通過建立配置項變量映射發(fā)現(xiàn)(即建立配置項名與源代碼中相應的程序變量名之間的映射關(guān)系)，目前常用開源軟件的配置項映射通常聚集于少量源文件的代碼段中，如 PostgreSQL 在“guc.c”文件中完成配置映射,Redis 在“config.c”文件中完成映射。通過統(tǒng)計發(fā)現(xiàn)，PostgreSQL軟件源碼中配置變量使用的分布情況如圖1所示，除了配置映射所在源文件外，其他源文件中的配置項出現(xiàn)次數(shù)極少，且分布稀疏 。

Figure 1 Positions Distribution of configurations圖1 配置變量使用位置分布

3.2 枚舉配置取值空間提取

基于上述配置映射特征，本文提取的對應配置項變量映射策略如下所示：通過分析配置變量在程序中實際使用的位置，判斷其可能的取值(宏或者枚舉)，通過可能的取值找到其配置項-配置變量映射代碼段，在代碼段中進行集中的配置約束提取，流程圖如圖 2 所示。相較于已有研究工作，本文的主要改進在于不需理解代碼語義信息，通過提供配置項名即可實現(xiàn)自動化的配置項變量映射特征代碼段，從而進一步實現(xiàn)配置約束的提取。

Figure 2 Extraction procedure of constraints for configurations圖2 枚舉配置變量取值空間的提取流程

3.2.1 枚舉配置變量取值提取

本文基于Clang前端的庫接口將所有的源代碼文件轉(zhuǎn)化為抽象語法樹AST(Abstract Syntax Tree)，并根據(jù)常見的2種配置變量(分支條件和選擇條件)使用場景分別進行配置變量取值的提取。

分支條件中的配置變量使用是最普遍的配置變量使用場景，其中的條件語句并非簡單的2個變量直接比較，而是存在復雜的邏輯操作判斷。因此，本文主要針對2種情況分別使用不同方法規(guī)范化條件語句并分析是否存在配置變量的使用。

首先，針對If-Condition類型的條件語句，本文主要使用二叉條件樹BCT(Binary Conditional Tree，即樹的所有葉節(jié)點均為操作數(shù)，而非葉節(jié)點均為操作符，每個非葉節(jié)點只有2個子樹)表示 if 語句中的條件表達式，其中葉節(jié)點為常量或變量，而非葉節(jié)點均為運算符。圖3即為1個基本的If語句分支條件的二叉條件樹。

Figure 3 An example of BCT圖3 BCT示例

基于BCT實現(xiàn)配置相關(guān)分支條件中的分析記錄具體步驟如下所示：

(1) 基于AST生成分支條件 BCT。基于 Clang 生成的源文件對應的AST，抽取配置相關(guān)的分支語句子樹，并生成對應 BCT。

(2) 基于預定規(guī)則簡化BCT。對于生成的 BCT，需要進行合并化簡，將表達式中較復雜的形式化簡為最簡單的等價形式。主要的化簡規(guī)則包括：

① 常量表達式運算，計算出表達式中的算術(shù)運算，例如“4+3”化簡為“7”；

② 與配置變量無關(guān)的子樹統(tǒng)一記為UNKNOWN節(jié)點；

③ 消除三元運算符，將三元運算符化簡為等價的二元運算符，如從“a?b:c”化簡為 “(ab)||(!ac)”。

然后通過遍歷整個BCT，查找是否出現(xiàn)了配置變量和宏定義/枚舉類型的直接比較，從而判斷出1個配置變量的1個可能取值。在圖3中，圓框為可以參與計算的葉子節(jié)點，方框葉節(jié)點分別為配置變量的可能值和配置變量。

除由 if 控制的分支條件外，switch 控制的選擇條件也是常用場景之一。其句法結(jié)構(gòu)相對比較簡單，不存在復雜的嵌套關(guān)系，與分支條件類似，選擇條件的配置變量使用分析也可以通過AST分析來實現(xiàn)。一般來說，switch語句的選擇條件AST滿足圖4所示形式，其中方框葉節(jié)點分別代表配置變量及其可能的取值?；谏鲜?種針對不同形式的配置變量使用情況獲取，即可獲得對應的配置變量使用情況。

Figure 4 BCT Features of ‘switch’ statement圖4 switch 語句 BCT 結(jié)構(gòu)特征

3.2.2 枚舉配置取值集中出現(xiàn)定位分析

在 PostgreSQL 中配置變量使用位置如圖 1 所示，橫坐標為文件，縱坐標為出現(xiàn)在該文件的第幾行，不同的灰度表示不同配置變量的枚舉值的使用位置。直觀來看，左下角是集中出現(xiàn)的區(qū)域，在實際計算中，以“數(shù)據(jù)距離不超過5行”作為集中定義區(qū)域的判定閾值。

3.2.3 基于AST的啟發(fā)式枚舉配置取值空間提取優(yōu)化

基于上述方法，如果通過簡單的字符串操作及固定的區(qū)域判定方法進行枚舉配置取值空間的提取，通常會存在一定的假陽性。本文主要通過以下方式進行過濾：首先，本文在調(diào)研過程中觀察到配置項字符串取值的字符一般為“A～Z”“a～z”“0～9”“-_”幾種類型的字符，而大部分假陽性是一些日志提示信息，含有大量的空格、“%”等符號，通過字符取值范圍過濾，可以過濾掉絕大多數(shù)的假陽性。進一步，本文對初步過濾后仍然存在的假陽性特征進行分析，發(fā)現(xiàn)假陽性主要來自于同處在集中定義代碼段的其他配置項的取值，以及其他配置項及自身配置項名稱本身，這些特征都無法從文本特征進行分析。因此，本文從抽象語法樹層面展開分析，通過分析字符串所在的抽象語法樹上下文結(jié)構(gòu)來判斷其是否為本配置項的1個可能取值。

前文在對AST進行詞頻統(tǒng)計，分析配置項的所有取值時，可以發(fā)現(xiàn)配置項名在每個代碼文件出現(xiàn)的頻率，進而可以確定取值的集中出現(xiàn)位置及對應源代碼文件(見圖4)。本文通過查看對應源碼文件發(fā)現(xiàn)，這些集中定義的代碼段，通常情況下為開發(fā)人員實現(xiàn)配置項取值空間和配置變量取值空間映射的代碼段。

通過進一步分析發(fā)現(xiàn)，在不同軟件中，實現(xiàn)配置映射的方式有所區(qū)別?？偟膩碚f可以總結(jié)為2種類型：結(jié)構(gòu)體映射和字符串比較。因此，在定位到集中定義代碼段之后，針對這2種固定的類型定義規(guī)律，可以針對對應特征分別實現(xiàn)提取配置項的值。

首先，針對結(jié)構(gòu)體映射的情況進行處理。配置變量定義于某個特定結(jié)構(gòu)體中，如代碼1所示，其第1個成員的第1個子成員表明配置項名稱“wal_level”，第2個成員(wal_level)表示其對應配置變量，第4個成員(wal_level_options)代表其映射的結(jié)構(gòu)體，其中存儲了所有可能的枚舉值，如代碼2所示。

代碼1 配置結(jié)構(gòu)體

{

{"wal_level", PCG_POSTMASTER,WAL_SETTINGS,

gettext_noop("set the level of information written to the WAL."),

NULL

},

&wal_level,

WAL_LEVEL_MINIMAL,wal_level_options,

NULL,NULL,NULL

}

代碼2 映射結(jié)構(gòu)體

/*PostgreSQL-9.3.1 guc.c*/

const struct config_enum_entry wal_level_options[]={

{"minimal",WAL_LEVEL_MINIMAL,false}，

{"archive",WAL_LEVEL_ARCHIVE,false},

{"hot_standby", WAL_LEVEL_HOT_STANDBY,false},

{NULL, 0, false}

}

本文通過調(diào)研發(fā)現(xiàn)，在大多數(shù)軟件中，配置項和配置變量的取值范圍都是通過上述方式定義的，具有一定的普遍性?；诖?，本文可以便捷地獲取配置項wal_level的取值空間定義結(jié)構(gòu)體wal_level_options及對應的枚舉取值空間。

另一方面，在少部分軟件中，程序判斷配置項枚舉值的方式是通過直接調(diào)用字符串比較函數(shù)，通過比對文件中或者用戶在終端輸入的配置項值與預設(shè)枚舉取值的方式為配置變量賦值。如代碼3所示，配置項 hostname_lookups 的可能取值為on、off、double，對應配置變量的可能取值為 HOSTNAME_LOOKUP_ON、 HOSTNAME_LOOKUP_OFF、HOSTNAME_LOOKUP_DOUBLE。針對這種情況，同樣可以通過抽象語法樹的分析獲取對應的枚舉配置取值空間。

代碼3 字符串直接比較

static const char *set_hostname_lookups(cmd_parms *cmd, void *d_, const char *arg)

{

core_dir_config *d=d_;

if (!strcasecmp(arg, "on")){

d→hostname_lookups = HOSTNAME_LOOKUP_ON;

}

else if (!strcasecmp(arg,"off")){

d→hostname_lookups = HOSTNAME_LOOKUP_OFF;

}

else if (!strcasecmp(arg,"double")){

d→hostname_lookups = HOSTNAME_LOOKUP_double;

}

else {

return "parameter must be 'on','off', or 'double'";

}

return NULL;}

綜合考慮上述2種情況，本文主要通過以下方法實現(xiàn)AST中的枚舉配置取值空間信息的分析和提?。号渲庙椀淖址≈岛推鋵某绦蚺渲米兞咳≈狄话愣汲霈F(xiàn)在同一InistListExpr 節(jié)點的子樹下(如圖5所示)。類似地，對于 Apache Httpd 這類軟件，一般字符串取值出現(xiàn)在strcasecmp 或者 strcmp 函數(shù)調(diào)用中，而相應的程序變量取值一般出現(xiàn)在后面的 if 語句塊中。針對上述2種情況，本文將其對應的stmt定義為特征 stmt，并針對特征 stmt 的結(jié)構(gòu)特征進行枚舉配置取值空間的定位與提取。具體方法為：

(1) 定義2個 AST stmt 的距離為在 AST 上從stmt1 到stmt2的路徑步數(shù)。

(2) 計算區(qū)域中所有字符串距離最近的父特征 stmt 的距離(僅向上訪問，若無父 stmt 則距離記為 INF)。

(3) 對于第1類特征 stmt，必須要求父特征 stmt 為同一 stmt，對于第2類，則計算是否共用一個 ifstmt。

(4) 對上述距離進行驗證(距離差距不能超過 1)，若正確，則提取對應配置取值。

通過對以上步驟編程實現(xiàn)，本文可自動獲取枚舉類型配置項的取值約束范圍。

Figure 5 Example of AST for value space of enumeration-type configuration圖5 枚舉類型配置取值空間AST示例圖

4 實驗與評估

本文首先對4款軟件(PostgreSQL，Apache Httpd，Nginx，Redis)的枚舉類型配置項數(shù)量進行了人工計數(shù)，得到實際的數(shù)量作為實驗評價的標準；然后使用本文的實現(xiàn)自動提取枚舉配置項取值空間，對應的提取準確率如表3所示。而在過去已有研究工作中[6]，僅對switch語句一種情況下的枚舉配置約束進行了提取，且沒有給出具體的提取率，本文使用已有方法提取4款開源軟件的枚舉型配置約束，發(fā)現(xiàn)已有研究的提取率在30%～70%，而本文方法則有較大提升，能夠處理常見的代碼特征如if-else語句，提取率均達到80%以上。

對于枚舉型配置項枚舉值的提取，本文將準確并完全地提取出某一配置變量的全部枚舉值認定為提取成功，有遺漏或者假陽性均為不成功。由此計算得到的提取率如表3所示。

Table 3 Rate of extraction and reason for failure表3 枚舉配置取值空間提取準確率

其中，部分實驗提取結(jié)果如表4所示(以 PostgreSQL-9.3.1 為例):

Table 4 Results of PostgreSQL extraction表4 PostgreSQL中枚舉配置取值空間提取結(jié)果

表4中，劃橫線的地方是使用了假陽性檢驗從而得以除去的取值。從結(jié)果來看，它們的確主要來自于其他配置項的取值空間，或者其他配置項的配置名稱，此外還有少部分來自于程序中其他語句的一些字符串提示、日志等信息。經(jīng)過對少部分失敗的原因進行分析發(fā)現(xiàn)，主要是軟件開發(fā)人員沒有使用規(guī)范化的編碼模式，如開發(fā)人員在配置變量位置使用的是宏定義類型的值，而在配置項集中賦值位置處使用的是整數(shù)類型，雖然不影響程序正確性，但屬于不良的編碼習慣。類似上述原因，導致本文總結(jié)的通用模式難以進行正確分析與提取。

5 結(jié)束語

在實際生產(chǎn)環(huán)境中，前人研究[6]已發(fā)現(xiàn)，如果用戶錯誤地設(shè)置了配置項的取值，很容易導致系統(tǒng)故障。提取枚舉類型配置項的取值空間可以讓用戶知道哪些值是合法的，從而減輕用戶配置軟件時的負擔，降低故障率。同時，基于提取結(jié)果，當出現(xiàn)故障時，開發(fā)人員可迅速診斷基于配置的故障原因，避免進行源碼分析。

通過對多款常用開源軟件的人工分析發(fā)現(xiàn)，現(xiàn)有用于提取配置約束條件的研究工作僅能提取少部分特定類型的配置約束，且對于常見的枚舉類型配置項約束提取的可用性較弱?；诖?，本文基于AST，對6款常用主流開源軟件配置處理使用相關(guān)源代碼進行分析，通過增加對分支條件和選擇條件的配置約束分析，設(shè)計和實現(xiàn)了一種針對枚舉類型的自動配置約束提取方法。實驗數(shù)據(jù)說明，該方法對所選各種軟件枚舉類型配置空間的提取準確率均超過80%。