MS家的工具还是可以的。UMDH的diff输出里，排名第一的基本就是leak点。

起因是端口被人占了，然后反复开socket尝试bind端口，反复泄漏socket。"占坑攻击"

// Each log entry has the following syntax:                                
//                                                                          
// + BYTES_DELTA (NEW_BYTES - OLD_BYTES) NEW_COUNT allocs BackTrace TRACEID
// + COUNT_DELTA (NEW_COUNT - OLD_COUNT) BackTrace TRACEID allocations      
//     ... stack trace ...                                                  
//                                                                          
// where:                                                                  
//                                                                          
//     BYTES_DELTA - increase in bytes between before and after log        
//     NEW_BYTES - bytes in after log                                      
//     OLD_BYTES - bytes in before log                                      
//     COUNT_DELTA - increase in allocations between before and after log  
//     NEW_COUNT - number of allocations in after log                      
//     OLD_COUNT - number of allocations in before log                      
//     TRACEID - decimal index of the stack trace in the trace database    
//         (can be used to search for allocation instances in the original  
//         UMDH logs).                                                      
//                                                                          


+1109bfc8 ( 40b71c88 - 2fad5cc0) 351987 allocs    BackTraceB3B27586
+   dfadf ( 351987 - 271ea8)    BackTraceB3B27586    allocations

    ntdll!RtlpAllocateHeapInternal+A7D
    MSWSOCK!SockSocket+1A5
    MSWSOCK!WSPSocket+23A
    WS2_32!WSASocketW+130
    WS2_32!socket+6E
        ...
    KERNEL32!BaseThreadInitThunk+14
    ntdll!RtlUserThreadStart+21

+ 2a8c5e0 ( 9f4a4f0 - 74bdf10) 3518c5 allocs    BackTraceB3B28106
+   e2eca ( 3518c5 - 26e9fb)    BackTraceB3B28106    allocations

    ntdll!RtlpAllocateHeapInternal+A7D
    WS2_32!WPUModifyIFSHandle+F8
    MSWSOCK!WSPSocket+28A
    WS2_32!WSASocketW+130
    WS2_32!socket+6E
        ...
    KERNEL32!BaseThreadInitThunk+14
    ntdll!RtlUserThreadStart+21

+ 294b490 ( 9bffd00 - 72b4870) 33fff0 allocs    BackTraceB3B28C86
+   dc3c3 ( 33fff0 - 263c2d)    BackTraceB3B28C86    allocations

    ntdll!RtlpAllocateHeapInternal+A7D
    ntdll!RtlpAddDebugInfoToCriticalSection+42
    ntdll!RtlInitializeCriticalSection+5CDD6
    MSWSOCK!SockSocket+318
    MSWSOCK!WSPSocket+23A
    WS2_32!WSASocketW+130
    WS2_32!socket+6E
        ...
    KERNEL32!BaseThreadInitThunk+14
    ntdll!RtlUserThreadStart+21
--
FROM 221.218.160.*

说明不够大啊，valgrind对 “大型c++程序“ 都load不起来
【 在 speedboy2998 的大作中提到: 】
: 在我的职业生涯中，我用过的，最好用最有效的内存泄漏工具是 Valgrind 和 Sanitizers.
: 曾经协助我在几个大型 C++ 程序中找到很复杂的内存泄漏。
:
--
FROM 47.96.236.*

很大了，几十万行代码。处理通讯的核心服务器

【 在 overcomeunic 的大作中提到: 】
: 说明不够大啊，valgrind对 “大型c++程序“ 都load不起来
--
FROM 218.76.62.*

valgrind大程序跑不动. 数据大,不是程序大.
【 在 speedboy2998 的大作中提到: 】
: 很大了，几十万行代码。处理通讯的核心服务器
:
--
FROM 1.88.51.*

绝对能。

【 在 xeagle 的大作中提到: 】
: 这么多年了，valgrind还能战吗
: 发自「今日水木 on iOS」
--
FROM 222.247.154.*