address-sanitizer

address-sanitizer 技能總覽

address-sanitizer 是做什麼的

address-sanitizer 技能可協助你使用 AddressSanitizer（ASan）在測試階段抓出記憶體安全漏洞，特別適合 fuzzing 與 crash triage。當你需要把含糊的「有東西在破壞記憶體」問題，縮小成可重現的堆疊追蹤、配置歷史或失敗測試案例時，它最有價值。

最適合的使用者與情境

這個 address-sanitizer 技能很適合 C/C++ 測試流程、fuzzing 管線，以及使用 unsafe 的 Rust 程式碼。對於想在升級到更深入人工分析前，先走一條實用 address-sanitizer for Security Audit 路徑的安全審查者，也很有幫助。

它的不同之處

ASan 不是一般的提示詞小技巧；它是一套編譯期插樁、執行期有取捨的工作流程。address-sanitizer 技能的主要價值，在於幫你判斷 ASan 是否是正確工具、它需要哪些輸入，以及如何避免因建置、旗標或環境不一致而產生誤導結果。

如何使用 address-sanitizer 技能

安裝技能

先依照你的 skill runner 預期的 repository 安裝流程操作，接著打開 skill bundle 裡的 SKILL.md，確認 address-sanitizer install 已成功。若你的環境支援 skill manifest，請確認名稱精確是 address-sanitizer，這樣你的 prompt router 才能觸發正確的指引。

提供正確的測試情境

好的 address-sanitizer usage 會先給出具體目標：語言、建置系統、測試指令、當機症狀，以及你是在做 fuzzing、執行 unit tests，還是重現問題。像「幫我用 ASan」這種模糊要求，不如這樣有效：「我有一個用 CMake 建置的 C++ 函式庫，fuzz target 會當掉，我需要 ASan flags 和最小重現流程。」

按這個順序閱讀技能檔案

先看 SKILL.md，再檢查你的環境所暴露的任何關聯 repository notes 或支援文件。對這個 repo path 而言，實際的閱讀順序是先找到主要指引，再查看涵蓋 overview、key concepts、when to apply 與 quick reference 的段落，這樣你在修改 build flags 之前，就能先掌握操作限制。

把粗略目標轉成可用提示詞

要得到最佳結果，請告訴技能你想證明什麼、你用哪個 compiler 和 test harness，以及成功標準是什麼。例子：我想找出 Linux C++ 服務中的 heap-use-after-free，這個服務是用 Clang 編譯的；請給我 ASan build flags、runtime options，以及從 fuzzing 執行結果出發的最短 triage 路徑。 這樣的描述，比起要求一個泛泛的說明，更能產生有用的 address-sanitizer guide 輸出。

address-sanitizer 技能 FAQ

address-sanitizer 只適合 fuzzing 嗎？

不是。fuzzing 很常見，但 address-sanitizer 技能也適用於 unit tests、regression tests，以及你懷疑有記憶體破壞時的 crash debugging。只要 bug 已經可以重現，ASan 往往仍是取得更清楚 stack trace 的最快途徑。

什麼情況下不該用它？

當你需要接近 production 的效能、你的目標平台或 toolchain 對它支援不好，或 bug 很可能跟 memory safety 無關時，就不該先用 ASan。若問題屬於純邏輯、協定層級，或只是效能問題，ASan 通常帶來的是雜訊而不是訊號。

它比一般提示詞更好嗎？

如果工作重點是偵測與 triage 記憶體錯誤，答案是肯定的。一般提示詞也許能概念性地解釋 ASan，但 address-sanitizer 技能在你需要一份可安裝、以工作流程為導向的指南時更有用，它能幫你更少猜測地選擇 flags、輸入與除錯步驟。

初學者也能用嗎？

可以，只要他們能描述自己的建置與測試設定即可。主要門檻不是要很懂 sanitizer，而是要有足夠的專案脈絡，說清楚語言、compiler、平台與重現路徑，讓技能能推薦正確的 ASan workflow。

如何改進 address-sanitizer 技能

提供建置與執行期細節

最好的 address-sanitizer 結果，來自精確的 compiler、平台與 test command 資訊。請一併說明你用的是 Clang 還是 GCC、目前已啟用哪些 sanitizer flags，以及故障是出現在 fuzz target、test binary，還是獨立 repro。

說明你懷疑的記憶體模式

當你描述具體症狀時，ASan 的輸出最能派上用場：out-of-bounds read、heap-use-after-free、stack overflow、double free 或 leak。若你只說「它當掉了」，技能就得推測太多，可能會建議錯誤的建置或 triage 路徑。

直接要求下一步除錯動作

拿到第一個答案後，請用最小幅度的後續問題持續推進：show me how to reduce this repro、help me interpret this stack trace，或 what ASan flags should I add for symbolization and better reports?。這能讓 address-sanitizer skill 聚焦在下一個真正重要的決策，而不是發散到廣泛的 sanitizer 理論。

注意常見失敗模式

最常見的錯誤，是沒有完整插樁就建置、把 sanitized 與 unsanitized 物件混在一起，以及把 ASan 當成可利用性的證明，而不是除錯訊號。如果你要用 address-sanitizer for Security Audit，請提供威脅模型和程式碼位置，讓輸出能區分已確認的記憶體破壞與純理論風險。