contributed by < AndybnACT
>
linux2020
為了讓 q_insert_tail
和 q_size
有 的時間複雜度,增加指向串列尾端的指標(tail
)、和表示元素數量(nr
)的欄位。接下來,只要在後面實作的函式中適當地更新這些資訊即可。
建立一個新的 queue ,然後將欄位初始化。若 malloc 失敗則在回報錯誤原因後返回 NULL。
將整個 queue 所佔據的記憶體空間釋放,包含每個節點內動態配置的資料欄位 value
。在這裡,用 while
迴圈走訪串列中各個節點,同時,用一個 self
指標來避免在刪除節點後,走訪下一個節點時發生 use-after-free。最後,記得把 queue 本身的空間也一並釋放。
將指定的節點內容 s
加入 queue 的最前端,然後更新 nr
。記得如果這是第一次在 queue 中插入節點(此時 tail
為空值),要順便將 tail
也一併初始化。過程中若 strdup
失敗,則要一併將新配置的節點空間釋放。
同理,將指定的節點內容 s
加入 queue 的尾端。我們可以直接從 q->tail
得到當前 queue 的尾端位置,直接操作、然後更新即可。這邊也透過 (!q->tail)
來判斷是否為第一次新增節點,然後做相應的處置。由於新增節點部分的程式碼與 q_insert_head
相同,未來開發可以考慮用一個函式呼叫取代之。
將 queue 首端的資料節點移除,節點內容複製到 sp
當中,然後釋放節點及資料所佔的空間。因為 strncpy
不會額外將 null terminator 寫在目標字串的尾端,在複製資料前,透過 memset
將 sp
的內容全部寫為零,避免在複製不完全的時候發生資料洩漏。同時,在移除最後一個節點的時候,我們必須將 q->tail
的值清空,避免之後 q_insert_tail
時發生 use-after-free。
直接回傳當前紀錄 queue 所擁有的節點數量。目前在透過 dudect
執行時間複雜度測試(trace-17)時,有時會回報為 Probably not constant time
,還未細究原因。
在不額外配置空間的限制下,將 queue 的節點次序反轉。函示用 prev
紀錄前一個節點的位置,然後將當前節點的下一個 cur->next
指向前一個節點、然後更新當前與前一個節點的位置。最後,再更新 queue 頭尾的位置。
透過 insertion sort 依據節點的字串排序 queue 。過程中,用兩個指標 head
及 tail
來紀錄排序後的首尾位置,每次從原本的 queue 拿出一個節點來對 head
指向的串列做插入排序。為了避免多餘的判斷(判斷插入點是否為串列首端),我們用指標的指標 list_ele_t **haystack
指向串列首端的位置 &head
,找到插入點之後,只需要將 *haystack
的位置更新為即將插入的節點、然後再將插入節點的下一個節點位置更新成原本 *haystack
指向的位置即可。記得,若探詢完插入點之後插入點位置為空值,代標即將插入的節點會是最後一個節點,此時要更新 tail
指標。
strnatcmp.[c|h]
檔案,放到 lab0-c
的目錄之中。q_sort
以及 do_sort
函式中的比較函式由 strcasecmp
換成 strnatcmp
,還要加上正確的 include
。queue.c:
qtest.c:
這邊可以把 #include <string.h>
移除
最後,在 Makefile
裡面 OBJS
變數尾端加上相應的 object file,也就是 strnatcmp.o
。
重新編譯,然後測試。使用的測試修改自 strnatcmp
的 GitHub repository:
traces/trace-18-natsort.cmd
測試完成後,發現 commit 時會被 pre-commit.hook 擋下。原因有二,一是新增檔案的 coding-style 不符合 clang-format
的要求,可以透過 clang-format -i <file>
解決。另外一個原因是靜態分析器建議將沒用到的函式 strnatcasecmp()
移除、還有一些變數的 scope
可以移至 while
迴圈裡面。
q->tail
之中。完成之後,make valgrind
以及使用 SANITIZER=1
編譯後的執行檔測試都沒有發現問題。merge
的尾端。通過測試的完整實作如下,queue.c
:
透過 make valgrind
檢查是否有記憶體錯誤,初步沒有看到任何錯誤訊息。
用 valgrind --tool=massif ./qtest
執行前,必須先將 .valgrindrc
裡面的 --show-leak-kinds=all
拿掉,可能是 massif
看不懂這個參數。成功執行 qtest
之後,簡單設計實驗觀察記憶體使用情況:
在 Massif 的參數裡面,可以指定是否追蹤 stack 的使用情形、以及最終圖表橫軸的呈現方式。圖表橫軸可以理解為時間軸,只是時間軸可以用真實的執行時間 (ms)、執行過的指令 (i)、或配置與釋放的記憶體容量總和 (B)。
實驗的方式是執行兩次 qtest
,實驗組與對照組,兩次實驗中,首先插入 10 個節點於 queue 裡面;之後執行不需要額外配置記憶體的 reverse
、和 (insertion) sort
;最後再將 queue 內部的節點一一釋放、結束程式。實驗組、對照組的差別在於實驗組在釋放節點的時候,使用會額外配置記憶體來暫存節點內部字串資訊的指令 rh
;而對照組選用單純、不令外配置空間的 rhq
指令來釋放節點。
在實驗組的 massif profile 當中,可以看到程式開始執行之後,記憶體用量逐步增加,應是程式初始化還有插入節點所致。然後有段時間用量持平,應該是在執行 reverse
以及 sort
。接著,顯著地看見 do_remove_head
導致用量增加。但事實上 do_remove_head
在執行結束前,還是會釋放暫存的字串空間;而 massif 卻沒有如實反映(這段時間折線圖理應在一範圍內上下來回擺動)。釋放完成之後,可以看到由 test_malloc
配置的空間已然消失,代表 queue 內部資料空間有被釋放。
在對照組當中,可以看到前半段(3e5 個指令之前)的 massif profile 大致同實驗組(2e5~3e5 的下降應該也是因為 massif 採樣不足所以略呈下降,理應持平)。後半段因為 rhq
不會另外配置空間暫存資料,所以記憶體用量逐步下降,最後歸零。
透過 Makefile
編譯時,加上選項 SANITIZER=1
,然後執行測試腳本
在第 17 道測試時發生錯誤
發現程式在 do_option_cmd
的時候,對 simulation
這個變數有越界讀取,詳請見 Commit #497391f。
將原本 int *valp
更改為 void *valp
使其支援多種型態的指標,然後用 valsize
描述指向區域內容物大小。
在 do_option_cmd
裡面,將原本對整數指標取值的行為改成 memcpy
然後在 add_param 裡面對 valsize 初始化、並將有關呼叫、宣告更新。
最後,因為 report
這個函式會需要取值,寫一個 generic_plist_getter
暫時滿足其需求
修改之後執行還是發生錯誤,這次是發生在 strlen
裡面
可見 Address Sanitizer 回報 random_string 尾端有 out-of-bound read 發生,詳請見 Commit 71b0892。
程式碼中發現在 get_random_string
中,對 random_string
存取的範圍是由 number_measurements
指定,為 150;然而,該陣列在宣告時大小只有 100 。
所以我們定義了一個巨集,然後讓宣告的陣列大小和 number_measurements
都由同一個巨集指定,順利解決問題。
Dude, is my code constant time? 是一篇 2016 年的論文。這篇論文主要的目的在用統計學「假設檢定」的方式來確認程式的執行時間不會因輸入的測資的差異而改變;進一步可以用來判斷旁通道攻擊中的 timming attack 對被測試程式的威脅程度。
這篇論文採用的實驗模型將測資分為兩個類型(classes),類型一為唯一固定測資、類型二為其他所有隨機測資的集合。採用的假設檢定為 Welch's t-test,檢定兩個母體的平均值是否有「顯著」差異。這種檢定方式不假設兩母體有同樣的標準差、亦不對兩種採樣的採樣數有所限制。
具體而言,lab0-c
實驗分成以下步驟:準備測資、測試、更新統計資料,若資料量足夠則進行假設檢定、反之重複準備測資…
首先,準備測資。固定測資採用長度為零的 empty queue;隨機測資則是不定長度(<1e4)、內容隨機的 queue。兩類型的測資被隨機打散在測試序列當中。每次執行測試時,測資的總數由 number_measurements
規範(實際上會減去兩倍的 drop_size
)
測試執行的方式如下,先將 queue 準備好,然後紀錄 q_size
(或 q_insert_tail
)的執行時間。
測試序列完成之後,將 before_ticks
與 after_ticks
相減得到執行時間,然後更新統計資訊。其中,t_push
為即時(Online)更新統計資訊的函式。
值得注意的地方是,根據論文描述,因為作業系統運作時中斷、行程切換的緣故,採樣結果通往往會有(skewwed)時間較長的傾向;因此,會將執行時間超過一定閥值的採樣點移除。然而,這樣的方法直接應用在這裡(測試是否為 )可能會有困難,所以沒有看到類似的程式碼。建議可以改成「移除前 10% 的資料點」達成類似的目標。
最後,進行假設檢定,此時若採樣點已湊齊(enough_measurements
),則假設檢定的結果具有意義,此時若檢定兩採樣的母體具有顯著差異性,就代表執行時間不是 constant time。