搜索论坛 帖子排序:  Oldest to newest Newest to oldest

2013-05-26, 13:38 下午 hyqhero 注册: 2013-04-26 发 贴: 8 使用umdh分析内存泄漏的疑惑，请张老师或其它大侠给予一些指点，万分感谢！ 问题1：请问使用umdh分析内存泄漏时最重要的注意事项是什么（是不是我哪个地方的设置不对，或符号文件的事）？---之所以这么问是因为~我感觉分析出来的结果（栈回溯）一部分看起来不太准确，例如我的exe并没有调用一个第三库的函数(接口)，却显示出这个库中有内存泄漏。。。 问题2：如果我的程序中有一个切换的逻辑，也就是说因为可能会出现“申请-释放-申请....”，（当然这种机制下我们使用了内存池），在什么时机用umdh抓取内存状态会更合适呢？因为我发现我隔几分钟抓取内存的对比结果都不太一样。例如：一个小时间抓一个内存状态1.txt，再过1个小时之后，抓一个内存状态2.txt，对比较这两个文件发现总共(total)涨了1M的内存，但是！！再过1分钟我再抓内存，发现变成降了100k的内存了，（从任务管理器内看虚拟内存和专用工作集都是涨的状态），这是怎么回事啊？是不是我抓的时机不对，是不是应该把程序停下来再抓？ 问题3：用umdh对比出来的内存泄漏为什么与任务管理器中显示的不太一样呢，如果对比发现总共涨了1M，任务管理器中看到却是2M或者更多（虚拟内存和专用工作集）。。问题是任务管理器中哪个列（虚拟内存or专用工作集or“其它”）的涨幅才是真正的能跟umdh中显示的对应一致上呢？ -------我的问题很多，非常感谢能够帮忙我们的人，虽然我们不曾见面，也没有报酬，但我想有很多默默伸出援手的人在这里，我们会永远地记住帮忙过我们的人，祝您一生快乐、平安。 IP 地址: 已记录   报告

2013-05-26, 20:03 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: 使用umdh分析内存泄漏的疑惑，请张老师或其它大侠给予一些指点，什么感谢！ 不怕问题多，但是要精确，因为泛泛而谈可能张冠李戴，毫无意义...... 拿出一个例子，copy, paste实际数据...   IP 地址: 已记录   报告

2013-06-03, 16:48 下午 hyqhero 注册: 2013-04-26 发 贴: 8 Re: 使用umdh分析内存泄漏的疑惑，请张老师或其它大侠给予一些指点，什么感谢！ 下面是我们在一个项目中使用umdh抓取的栈回溯信息   +  650160 ( 1160880 - 510720)  13820 allocs BackTrace31A74AA0 +    7740 (  13820 -   6080) BackTrace31A74AA0 allocations  ntdll!EtwSetMark+0000244D  KERNELBASE!LocalAlloc+00000058  nslook!CNoTrackObject::operator new+00000010 (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp, 78)  nslook!CThreadLocal<AFX_MODULE_THREAD_STATE>::CreateObject+00000007 (f:\dd\vctools\vc7libs\ship\atlmfc\include\afxtls_.h, 198)  nslook!CThreadLocal<AFX_MODULE_THREAD_STATE>::GetData+0000000A (f:\dd\vctools\vc7libs\ship\atlmfc\include\afxtls_.h, 178)  nslook!__DllMainCRTStartup+0000006C (f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c, 318)  nslook!_DllMainCRTStartup+0000001E (f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c, 281)  ntdll!wcsncmp+0000004C  ntdll!LdrShutdownThread+000000E2  ntdll!RtlExitUserThread+0000002A  PlaySdkM4!_endthreadex+0000004A (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 414)  PlaySdkM4!_callthreadstartex+00000059 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 348)  PlaySdkM4!_threadstartex+000000A4 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 331) +  650160 ( 1160880 - 510720)  13820 allocs BackTrace31A72D8C +    7740 (  13820 -   6080) BackTrace31A72D8C allocations  ntdll!EtwSetMark+0000244D  KERNELBASE!LocalAlloc+00000058  NVDSDK!DEC_ClientSetMsgCallback+000179EE  NVDSDK!DEC_ClientSetMsgCallback+00017380  NVDSDK!DEC_ClientSetMsgCallback+00017454  NVDSDK!DEC_ClientSetMsgCallback+00022A2E  NVDSDK!DEC_ClientSetMsgCallback+00022AD6  ntdll!wcsncmp+0000004C  ntdll!LdrShutdownThread+000000E2  ntdll!RtlExitUserThread+0000002A  PlaySdkM4!_endthreadex+0000004A (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 414)  PlaySdkM4!_callthreadstartex+00000059 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 348)  PlaySdkM4!_threadstartex+000000A4 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 331) +  123840 ( 221056 -  97216)  13816 allocs BackTrace31A749B8 +    7740 (  13816 -   6076) BackTrace31A749B8 allocations  ntdll!EtwSetMark+0000244D  KERNELBASE!LocalAlloc+00000058  nslook!CNoTrackObject::operator new+00000010 (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp, 78)  nslook!CThreadSlotData::SetValue+0000007C (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp, 291)  nslook!CThreadLocalObject::GetData+00000080 (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp, 432)  nslook!AfxGetModuleState+0000000F (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxstate.cpp, 456)  nslook!__DllMainCRTStartup+0000006C (f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c, 318)  nslook!_DllMainCRTStartup+0000001E (f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c, 281)  ntdll!wcsncmp+0000004C  ntdll!LdrShutdownThread+000000E2  ntdll!RtlExitUserThread+0000002A  PlaySdkM4!_endthreadex+0000004A (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 414)  PlaySdkM4!_callthreadstartex+00000059 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 348)  PlaySdkM4!_threadstartex+000000A4 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 331) +  123840 ( 221104 -  97264)  13819 allocs BackTrace31A72CA4 +    7740 (  13819 -   6079) BackTrace31A72CA4 allocations  ntdll!EtwSetMark+0000244D  KERNELBASE!LocalAlloc+00000058  NVDSDK!DEC_ClientSetMsgCallback+000179EE  NVDSDK!DEC_ClientSetMsgCallback+00017E3F  NVDSDK!DEC_ClientSetMsgCallback+00018086  NVDSDK!DEC_ClientSetMsgCallback+00017969  NVDSDK!DEC_ClientSetMsgCallback+00022A2E  NVDSDK!DEC_ClientSetMsgCallback+00022AD6  ntdll!wcsncmp+0000004C  ntdll!LdrShutdownThread+000000E2  ntdll!RtlExitUserThread+0000002A  PlaySdkM4!_endthreadex+0000004A (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 414)  PlaySdkM4!_callthreadstartex+00000059 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 348)  PlaySdkM4!_threadstartex+000000A4 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 331) +   92880 ( 165816 -  72936)  13818 allocs BackTrace31A72D38 +    7740 (  13818 -   6078) BackTrace31A72D38 allocations  ntdll!EtwSetMark+0000244D  KERNELBASE!LocalAlloc+00000058  NVDSDK!DEC_ClientSetMsgCallback+00017E33  NVDSDK!DEC_ClientSetMsgCallback+00018086  NVDSDK!DEC_ClientSetMsgCallback+00017969  NVDSDK!DEC_ClientSetMsgCallback+00022A2E  NVDSDK!DEC_ClientSetMsgCallback+00022AD6  ntdll!wcsncmp+0000004C  ntdll!LdrShutdownThread+000000E2  ntdll!RtlExitUserThread+0000002A  PlaySdkM4!_endthreadex+0000004A (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 414)  PlaySdkM4!_callthreadstartex+00000059 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 348)  PlaySdkM4!_threadstartex+000000A4 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 331) +   92880 ( 165828 -  72948)  13819 allocs BackTrace31A74A4C +    7740 (  13819 -   6079) BackTrace31A74A4C allocations  ntdll!EtwSetMark+0000244D  KERNELBASE!LocalAlloc+00000058  nslook!CThreadSlotData::SetValue+00000070 (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp, 310)  nslook!CThreadLocalObject::GetData+00000080 (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp, 432)  nslook!AfxGetModuleState+0000000F (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxstate.cpp, 456)  nslook!__DllMainCRTStartup+0000006C (f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c, 318)  nslook!_DllMainCRTStartup+0000001E (f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c, 281)  ntdll!wcsncmp+0000004C  ntdll!LdrShutdownThread+000000E2  ntdll!RtlExitUserThread+0000002A  PlaySdkM4!_endthreadex+0000004A (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 414)  PlaySdkM4!_callthreadstartex+00000059 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 348)  PlaySdkM4!_threadstartex+000000A4 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 331) 这是内存涨得最多的几个栈信息，都是调到了我们项目中的一个库PlaysdkM4调到了ntdll 再从ntdll调回我们项目中没有使用的库，很奇怪。 而且更匪夷所思的是_beginthreadex这个函数涨内存，上网查了可能是和tiddata结构体有关，我们还特地在线程中直接返回0并在线程退出前显式的调用_endthreadex（0）内存仍然涨在这。 上面贴的栈是没有调_endthreadex的 IP 地址: 已记录   报告

2013-06-03, 19:53 下午 hyqhero 注册: 2013-04-26 发 贴: 8 Re: 使用umdh分析内存泄漏的疑惑，请张老师或其它大侠给予一些指点，什么感谢！ 下面是我刚刚抓的显示调用_endthreadex(0)umdp 2小时后对比的结果，和上面几乎一样，nslook和nvdsdk在老化过程总没用逻辑调用到。而且更不可能从ntdll调上来。   + 6436080 ( 7081200 - 645120)  84300 allocs BackTrace2E883B60 +   76620 (  84300 -   7680) BackTrace2E883B60 allocations  ntdll!RtlAllocateHeap+00000274  KERNELBASE!LocalAlloc+0000005F  nslook!CNoTrackObject::operator new+00000010 (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp, 78)  nslook!CThreadLocal<AFX_MODULE_THREAD_STATE>::CreateObject+00000007 (f:\dd\vctools\vc7libs\ship\atlmfc\include\afxtls_.h, 198)  nslook!CThreadLocal<AFX_MODULE_THREAD_STATE>::GetData+0000000A (f:\dd\vctools\vc7libs\ship\atlmfc\include\afxtls_.h, 178)  nslook!__DllMainCRTStartup+0000006C (f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c, 318)  nslook!_DllMainCRTStartup+0000001E (f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c, 281)  ntdll!LdrpCallInitRoutine+00000014  ntdll!LdrShutdownThread+000000E6  ntdll!RtlExitUserThread+0000002A  PlaySdkM4!_endthreadex+0000004A (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 414)  PlaySdkM4!PlayThreadtest+0000000A (f:\windows sdk\windows\playsdkm4\trunk\source\sourcecode\player\player.cpp, 669)  PlaySdkM4!_callthreadstartex+00000053 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 348)  PlaySdkM4!_threadstartex+000000A4 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 331) + 6436080 ( 7081200 - 645120)  84300 allocs BackTrace2E8819CC +   76620 (  84300 -   7680) BackTrace2E8819CC allocations  ntdll!RtlAllocateHeap+00000274  KERNELBASE!LocalAlloc+0000005F  NVDSDK!DEC_ClientSetMsgCallback+000179EE  NVDSDK!DEC_ClientSetMsgCallback+00017380  NVDSDK!DEC_ClientSetMsgCallback+00017454  NVDSDK!DEC_ClientSetMsgCallback+00022A2E  NVDSDK!DEC_ClientSetMsgCallback+00022AD6  ntdll!LdrpCallInitRoutine+00000014  ntdll!LdrShutdownThread+000000E6  ntdll!RtlExitUserThread+0000002A  PlaySdkM4!_endthreadex+0000004A (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 414)  PlaySdkM4!PlayThreadtest+0000000A (f:\windows sdk\windows\playsdkm4\trunk\source\sourcecode\player\player.cpp, 669)  PlaySdkM4!_callthreadstartex+00000053 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 348)  PlaySdkM4!_threadstartex+000000A4 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 331) + 1225728 ( 1348576 - 122848)  84286 allocs BackTrace2E883A38 +   76608 (  84286 -   7678) BackTrace2E883A38 allocations  ntdll!RtlAllocateHeap+00000274  KERNELBASE!LocalAlloc+0000005F  nslook!CNoTrackObject::operator new+00000010 (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp, 78)  nslook!CThreadSlotData::SetValue+0000007C (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp, 291)  nslook!CThreadLocalObject::GetData+00000080 (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp, 432)  nslook!AfxGetModuleState+0000000F (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxstate.cpp, 456)  nslook!__DllMainCRTStartup+0000006C (f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c, 318)  nslook!_DllMainCRTStartup+0000001E (f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c, 281)  ntdll!LdrpCallInitRoutine+00000014  ntdll!LdrShutdownThread+000000E6  ntdll!RtlExitUserThread+0000002A  PlaySdkM4!_endthreadex+0000004A (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 414)  PlaySdkM4!PlayThreadtest+0000000A (f:\windows sdk\windows\playsdkm4\trunk\source\sourcecode\player\player.cpp, 669)  PlaySdkM4!_callthreadstartex+00000053 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 348)  PlaySdkM4!_threadstartex+000000A4 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 331) + 1225728 ( 1348576 - 122848)  84286 allocs BackTrace2E8818A4 +   76608 (  84286 -   7678) BackTrace2E8818A4 allocations  ntdll!RtlAllocateHeap+00000274  KERNELBASE!LocalAlloc+0000005F  NVDSDK!DEC_ClientSetMsgCallback+000179EE  NVDSDK!DEC_ClientSetMsgCallback+00017E3F  NVDSDK!DEC_ClientSetMsgCallback+00018086  NVDSDK!DEC_ClientSetMsgCallback+00017969  NVDSDK!DEC_ClientSetMsgCallback+00022A2E  NVDSDK!DEC_ClientSetMsgCallback+00022AD6  ntdll!LdrpCallInitRoutine+00000014  ntdll!LdrShutdownThread+000000E6  ntdll!RtlExitUserThread+0000002A  PlaySdkM4!_endthreadex+0000004A (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 414)  PlaySdkM4!PlayThreadtest+0000000A (f:\windows sdk\windows\playsdkm4\trunk\source\sourcecode\player\player.cpp, 669)  PlaySdkM4!_callthreadstartex+00000053 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 348)  PlaySdkM4!_threadstartex+000000A4 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 331) +  919332 ( 1011456 -  92124)  84288 allocs BackTrace2E881938 +   76611 (  84288 -   7677) BackTrace2E881938 allocations  ntdll!RtlAllocateHeap+00000274  KERNELBASE!LocalAlloc+0000005F  NVDSDK!DEC_ClientSetMsgCallback+00017E33  NVDSDK!DEC_ClientSetMsgCallback+00018086  NVDSDK!DEC_ClientSetMsgCallback+00017969  NVDSDK!DEC_ClientSetMsgCallback+00022A2E  NVDSDK!DEC_ClientSetMsgCallback+00022AD6  ntdll!LdrpCallInitRoutine+00000014  ntdll!LdrShutdownThread+000000E6  ntdll!RtlExitUserThread+0000002A  PlaySdkM4!_endthreadex+0000004A (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 414)  PlaySdkM4!PlayThreadtest+0000000A (f:\windows sdk\windows\playsdkm4\trunk\source\sourcecode\player\player.cpp, 669)  PlaySdkM4!_callthreadstartex+00000053 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 348)  PlaySdkM4!_threadstartex+000000A4 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 331) +  919308 ( 1011444 -  92136)  84287 allocs BackTrace2E883ACC +   76609 (  84287 -   7678) BackTrace2E883ACC allocations  ntdll!RtlAllocateHeap+00000274  KERNELBASE!LocalAlloc+0000005F  nslook!CThreadSlotData::SetValue+00000070 (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp, 310)  nslook!CThreadLocalObject::GetData+00000080 (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp, 432)  nslook!AfxGetModuleState+0000000F (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxstate.cpp, 456)  nslook!__DllMainCRTStartup+0000006C (f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c, 318)  nslook!_DllMainCRTStartup+0000001E (f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c, 281)  ntdll!LdrpCallInitRoutine+00000014  ntdll!LdrShutdownThread+000000E6  ntdll!RtlExitUserThread+0000002A  PlaySdkM4!_endthreadex+0000004A (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 414)  PlaySdkM4!PlayThreadtest+0000000A (f:\windows sdk\windows\playsdkm4\trunk\source\sourcecode\player\player.cpp, 669)  PlaySdkM4!_callthreadstartex+00000053 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 348)  PlaySdkM4!_threadstartex+000000A4 (f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c, 331) IP 地址: 已记录   报告

2013-06-04, 09:58 上午 嘻哈 注册: 2013-06-04 发 贴: 2 Re: 使用umdh分析内存泄漏的疑惑，请张老师或其它大侠给予一些指点，什么感谢！ 每个DLL都可以有一个入口点函数DllMain,系统会在不同的时刻调用此函数。以下是DllMain的一般形式： BOOL WINAPI DllMain( HINSTANCE hinstDLL, // handle to DLL module DWORD fdwReason, // reason for calling function LPVOID lpReserved ) // reserved { // Perform actions based on the reason for calling. switch( fdwReason ) { case DLL_PROCESS_ATTACH: // Initialize once for each new process. // Return FALSE to fail DLL load. break; case DLL_THREAD_ATTACH: // Do thread-specific initialization. break; case DLL_THREAD_DETACH: // Do thread-specific cleanup. break; case DLL_PROCESS_DETACH: // Perform any necessary cleanup. break; } return TRUE; // Successful DLL_PROCESS_ATTACH. } 以上代码摘自MSDN，几乎所有的DllMain都以这种形式呈现。 先来看一下这个函数传递进来的参数： 1、 HINSTANCE hinstDLL 这个参数是该DLL实例的句柄，也就是此DLL映射到进程地址空间后，在该进程地址空间中的位置。 2、 DWORD fdwReason 此参数标示了调用DllMain函数的原因。有四种值，就是函数中case后的取值。各个取值的含义，稍后论述。 3、 LPVOID lpReserved 保留。 现在我们来讨论一下fdwReason的四种取值，这些取值，也直接反映了操作系统会在何种情况下调用DllMain。 1、DLL_PROCESS_ATTACH 当系统第一次将一个DLL映射到进程地址空间中时，会调用DllMain，并为fdwReason传入DLL_PROCESS_ATTACH。 注意，只有在第一次映射的时候，才会这样。如之后，另一线程再次显式加载此DLL，则操作系统只是增加该DLL的使用计数，而不会再次使用DLL_PROCESS_ATTACH来调用DllMain。 对DLL_PROCESS_ATTACH的处理，代表了DLL的初始化。 DllMain的返回值，也是针对DLL_PROCESS_ATTACH消息的。对于其余的三种取值，不起作用。 对于隐式加载，如DllMain返回FALSE，则程序会启动失败。对于显式加载，则会使LoadLibrary返回NULL。 2、DLL_PROCESS_DETACH 当系统将一个DLL从进程地址空间中撤销映射时，则会向DllMain传入DLL_PROCESS_DETACH。我们应当在此处放置一些清理代码。 当使用FreeLibrary时，如该线程的使用计数为0时，操作系统才会使用DLL_PROCESS_DETACH来调用DllMain。如使用计数大于0，则只是单纯的减少该DLL的计数。 3、DLL_THREAD_ATTACH 当进程创建一个线程，则系统会检查当前已映射到该进程空间中的所有DLL映像，并用DLL_THREAD_ATTACH来调用每个DLL的DllMain。 只有当所有DLL都完成了对DLL_THREAD_ATTACH的处理后，新线程才会执行它的线程函数。 另外，主线程不可能用DLL_THREAD_ATTACH来调用DllMain，因为主线程必然是在进程初始化的时候，用DLL_PROCESS_ATTACH调用DllMain的。 4、DLL_THREAD_DETACH 线程若要终止，会调用ExitThread，但是此函数不会立即终止线程，而是会利用DLL_THREAD_DETACH来调用当前进程地址空间中的所有DLL镜像的DllMain. 当每个DLL的DllMain都处理完后，系统才会真正的结束线程。 最后看一下DllMain的序列化调用 举个例子： 进程中有两个线程，A与B。进程的地址空间中，映射了一个名为SomeDll.dll的DLL。两个线程都准备通过CreateThread来创建另两个线程，C和D。 当线程A调用CreateThread来创建线程C的时候，系统会用DLL_THREAD_ATTACH来调用SomeDll.dll的DllMain，当线程C执行其中代码的时候，线程B调用CreateThread来创建线程D。 这时，系统同样会用DLL_THREAD_ATTACH来调用SomeDll.dll的DllMain，这次是让线程D来执行其中的代码。 但是此时，系统会对DllMain执行序列化，它会将线程D挂起，直至线程C执行完DllMain中的代码返回为止。 当C线程执行完DllMain中的代码并返回时，可以继续执行C的线程函数。此时，系统会唤醒线程D，让D执行DllMain中的代码。当返回后，线程D开始执行线程函数。 IP 地址: 已记录   报告

2013-06-04, 10:00 上午 嘻哈 注册: 2013-06-04 发 贴: 2 Re: 使用umdh分析内存泄漏的疑惑，请张老师或其它大侠给予一些指点，什么感谢！ 张老师，现在的疑惑是nslook和nvdsdk都没有显式的dllmain函数，DLL_THREAD_ATTACH和DLL_THREAD_DETACH是怎样的？   IP 地址: 已记录   报告

2013-06-04, 22:09 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: 使用umdh分析内存泄漏的疑惑，请张老师或其它大侠给予一些指点，什么感谢！ 如果用户代码没有写DllMain，那么编译器会使用dummy的DllMain，CRT源代码中可以找到： 比如C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src\ BOOL WINAPI DllMain(         HANDLE  hDllHandle,         DWORD   dwReason,         LPVOID  lpreserved         ) { #if defined (CRTDLL)         if ( dwReason == DLL_PROCESS_ATTACH && ! _pRawDllMain )                 DisableThreadLibraryCalls(hDllHandle); #endif  /* defined (CRTDLL) */         return TRUE ; } BOOL WINAPI _DllMainCRTStartup(         HANDLE  hDllHandle,         DWORD   dwReason,         LPVOID  lpreserved         ) { // ...       // invoke DllMain();         if ( (dwReason == DLL_PROCESS_DETACH) ||              (dwReason == DLL_THREAD_DETACH) )         {             if ( _CRT_INIT(hDllHandle, dwReason, lpreserved) == FALSE )                 retcode = FALSE ; // ... } 建议使用WinDBG附加到目标进程，跟踪一下就清楚了... IP 地址: 已记录   报告

高端调试 » 软件调试 » WinDbg » Re: 使用umdh分析内存泄漏的疑惑，请张老师或其它大侠给予一些指点，什么感谢！

请选择 论坛首页 |- 论坛搜索 |- 热门主题 |- 未回复的主题 用户选项 |- 登录 |- 注册 |- 找回密码 软件调试 |- Windows内核调试 |- C/C++本地代码调试 |- .Net程序调试 |- 脚本程序调试 |- Java程序调试 |- Linux内核调试 |- 《程序员》杂志调试专栏 |- WinDbg |- GDB |- 远程调试 |- 调试ACPI和BIOS |- 特殊的调试任务 |- 转储分析 |- GDK7 内核探秘 |- Windows内核 |- Linux内核 系统架构 |- CPU架构 |- PCI/PCI Express架构 程序人生 |- 软件物语 |- 社区活动 |- 名人逸事 联盟论坛 |- 欢迎使用CnForums 没有银弹 |- BUG也精彩 |- 豆腐工程 |- 软件圈里十大怪 Windows Vista |- 用调试利剑剖析VISTA内幕 |- 老专家如何破解新问题 |- 我的电脑谁说了算？ |- 资源 Office开发 |- Visio 驱动程序开发 |- Windows驱动开发 |- Linux驱动开发 |- Windows CE驱动开发 用户态开发 |- Windows本地代码（native）高级开发 |- Web应用开发 |- WinFX和.Net |- Office开发 本站建设 |- 高端调试团队 |- 版面布局 |- 活动建议 |- 网站维护 64位计算 |- 64-bit Windows |- 64-bit CPU 图书 |- 《软件调试》的示例程序 |- 《软件调试》的工具 |- 《软件调试》书友 |- 《软件调试》答疑 |- 《软件调试》勘误和意见 |- 《格蠹汇编》 |- 《软件调试》第二版卷1 |- 《软件调试》第二版卷2 云计算 |- IaaS |- 云存储 |- 大数据 |- PaaS和SaaS GPU |- CUDA |- OpenCL |- HSA |- 游戏开发与调试