對Asan原理有興趣的同學可以參考asan的算法這篇文章，它的實現原理就是在程序代碼中插入壹些自定義代碼，如下：
編譯前：
*address = ...; // or: ... = *address;
編譯後：
if (IsPoisoned(address)) {undefined
ReportError(address, kAccessSize, kIsWrite);
}
*address = ...; // or: ... = *address;`
和valgrind明顯不同的是，asan需要添加編譯開關重新編譯程序，好在不需要自己修改代碼。而valgrind不需要編程程序就能直接運行。
address sanitizer集成在了clang編譯器中，GCC 4.8版本以上才支持。我們線上程序默認都是使用gcc4.3編譯，於是我測試時直接使用clang重新編譯nginx：
--with-cc="clang" \
--with-cc-opt="-g -fPIC -fsanitize=address -fno-omit-frame-pointer"
其中with-cc是指定編譯器，with-cc-opt指定編譯選項， -fsanitize=address就是開啟AddressSanitizer功能。
由於AddressSanitizer對nginx的影響較小，所以大壓力測試時也能達到上萬的並發，內存泄漏的問題很容易就定位了。
這裏就不詳細介紹內存泄漏的原因了，因為跟openssl的錯誤處理邏輯有關，是我自己實現的，沒有普遍的參考意義。
最重要的是，知道valgrind和asan的使用場景和方法，遇到內存方面的問題能夠快速修復。
性能熱點分析
到此，經過改造的nginx程序沒有core dump和內存泄漏方面的風險了。但這顯然不是我們最關心的結果（因為代碼本該如此），我們最關心的問題是：
1. 代碼優化前，程序的瓶頸在哪裏？能夠優化到什麽程度？
2. 代碼優化後，優化是否徹底？會出現哪些新的性能熱點和瓶頸？
這個時候我們就需要壹些工具來檢測程序的性能熱點。
perf，oprofile，gprof，systemtap