It looks like a some kind of race condition, still occurs in the latest version of VLD.
↧
New Post: VLD 2.0, VC++2005, Crash after stack overflow on calling RtlAllocateHeap() from vldnew()
↧
New Post: Visual Studio 2013
I just verified this myself. I created a regular wizard template MFC app in VS 2013, added a malloc() at init and VLD didn't see it.
I changed the toolset to VS 2012 and it worked fine.
Well we shouldn't be surprised as the title for this project clearly states it's for 2008/2010/2012.
edit: I just cruised through the source and I see where each CRT version is hooked into (dllspatches.cpp). The VS 2013 CRT will need to have it's own entry - and something tells me it ain't as simple as that...
I changed the toolset to VS 2012 and it worked fine.
Well we shouldn't be surprised as the title for this project clearly states it's for 2008/2010/2012.
edit: I just cruised through the source and I see where each CRT version is hooked into (dllspatches.cpp). The VS 2013 CRT will need to have it's own entry - and something tells me it ain't as simple as that...
↧
↧
New Post: endless recursive call to VLD itself
hello,
I found a bug of VLD: endless recursive call to VLD itself. The callstack is as the following.
It's just because getTls() calls TlsSetValue() API, and TlsSetValue() calls RtlAllocateHeap(), but heap allocation is hooked by VLD, so the recursion is endless.
I found a bug of VLD: endless recursive call to VLD itself. The callstack is as the following.
It's just because getTls() calls TlsSetValue() API, and TlsSetValue() calls RtlAllocateHeap(), but heap allocation is hooked by VLD, so the recursion is endless.
vld_x86.dll!VisualLeakDetector::getTls() Line 983 C++
vld_x86.dll!VisualLeakDetector::enabled() Line 904 + 0x8 bytes C++
vld_x86.dll!VisualLeakDetector::_HeapAlloc(void * heap=0x00610000, unsigned long flags=8, unsigned long size=4096) Line 1544 + 0x10 bytes C++
KernelBase.dll!_TlsSetValue@8() + 0x45f04 bytes
vld_x86.dll!VisualLeakDetector::getTls() Line 996 + 0x16 bytes C++
vld_x86.dll!VisualLeakDetector::enabled() Line 904 + 0x8 bytes C++
vld_x86.dll!VisualLeakDetector::_HeapAlloc(void * heap=0x00610000, unsigned long flags=8, unsigned long size=4096) Line 1544 + 0x10 bytes C++
KernelBase.dll!_TlsSetValue@8() + 0x45f04 bytes
vld_x86.dll!VisualLeakDetector::getTls() Line 996 + 0x16 bytes C++
vld_x86.dll!VisualLeakDetector::enabled() Line 904 + 0x8 bytes C++
vld_x86.dll!VisualLeakDetector::_HeapAlloc(void * heap=0x00610000, unsigned long flags=8, unsigned long size=4096) Line 1544 + 0x10 bytes C++
KernelBase.dll!_TlsSetValue@8() + 0x45f04 bytes
vld_x86.dll!VisualLeakDetector::getTls() Line 996 + 0x16 bytes C++
vld_x86.dll!VisualLeakDetector::enabled() Line 904 + 0x8 bytes C++
vld_x86.dll!VisualLeakDetector::_HeapAlloc(void * heap=0x00610000, unsigned long flags=8, unsigned long size=4096) Line 1544 + 0x10 bytes C++
KernelBase.dll!_TlsSetValue@8() + 0x45f04 bytes
vld_x86.dll!VisualLeakDetector::getTls() Line 996 + 0x16 bytes C++
vld_x86.dll!VisualLeakDetector::enabled() Line 904 + 0x8 bytes C++
vld_x86.dll!VisualLeakDetector::_HeapAlloc(void * heap=0x00610000, unsigned long flags=8, unsigned long size=4096) Line 1544 + 0x10 bytes C++↧
New Post: VLD 2.0, VC++2005, Crash after stack overflow on calling RtlAllocateHeap() from vldnew()
not race condition. The hook routine of RtlAllocateHeap just indirectly calls RtlAllocateHeap itself, so the endless recursive call occurs and leads to stack overflow.
call chain((actually a loop):
RtlAllocateHeap -> RtlAllocateHeap hook routine ->enabled ->gettls -> TlsSetValue -> VirtualUnlock -> RtlAllocateHeap
call chain((actually a loop):
RtlAllocateHeap -> RtlAllocateHeap hook routine ->enabled ->gettls -> TlsSetValue -> VirtualUnlock -> RtlAllocateHeap
↧
Created Unassigned: I want to know visual leak detector only supports the UNICODE character set code?It also supports UTF -8? [10552]
I want to know visual leak detector only supports the UNICODE character set code?It also supports UTF -8? Our code supports UTF -8, so I want to know that whether vld is useful? thanks.
↧
↧
New Post: Visual Studio 2013
Yeah I know it's not "supposed" t work with vs2013. So I didn't mean to say that as a complaint lol.
But if someone found a somewhat feasible workaround or any knowledge of when VLD would be updated. Or what we'd need to do to update it would be cool.
But if someone found a somewhat feasible workaround or any knowledge of when VLD would be updated. Or what we'd need to do to update it would be cool.
↧
Commented Issue: Static CRT leaks? [10446]
<p>I use Visual Studio 2012 and VLD 2.2.3.</p>
<p>Compile option /MTd.</p>
<p>Memory leak is reported with the next code.</p>
<p> </p>
<p>int _tmain(int argc, _TCHAR* argv[])</p>
<p>{</p>
<p> return 0;</p>
<p>}</p>
<p> </p>
<p>VisualLeakDetector::_HeapCreate() dose not seem to be called...</p>
<p> </p>
<p>*I use machine translation, I cannot express it well.</p>
Comments: Same here--- Is this a VisualLeakDetector problem or is this the CRT??? I can believe the CRT leaks, but WHY doesn't VLD have a way to "screen out" these reports? if they're known, then just give us an .INI entry to automatically ignore faults of this type... OR is it that VLD exits before the CRT cleans up?
<p>Compile option /MTd.</p>
<p>Memory leak is reported with the next code.</p>
<p> </p>
<p>int _tmain(int argc, _TCHAR* argv[])</p>
<p>{</p>
<p> return 0;</p>
<p>}</p>
<p> </p>
<p>VisualLeakDetector::_HeapCreate() dose not seem to be called...</p>
<p> </p>
<p>*I use machine translation, I cannot express it well.</p>
Comments: Same here--- Is this a VisualLeakDetector problem or is this the CRT??? I can believe the CRT leaks, but WHY doesn't VLD have a way to "screen out" these reports? if they're known, then just give us an .INI entry to automatically ignore faults of this type... OR is it that VLD exits before the CRT cleans up?
↧
New Post: Visual Studio 2013
Hey. So I updated the patches with the vs2013 alternatives. and it seems to have worked. gonna do some testing to see what else changed.
↧
Source code checked in, #01e53e5edafd007afac3593df0b396639ffd4ba5
VS 2013 support added
↧
↧
Commented Issue: Static CRT leaks? [10446]
<p>I use Visual Studio 2012 and VLD 2.2.3.</p>
<p>Compile option /MTd.</p>
<p>Memory leak is reported with the next code.</p>
<p> </p>
<p>int _tmain(int argc, _TCHAR* argv[])</p>
<p>{</p>
<p> return 0;</p>
<p>}</p>
<p> </p>
<p>VisualLeakDetector::_HeapCreate() dose not seem to be called...</p>
<p> </p>
<p>*I use machine translation, I cannot express it well.</p>
Comments: I have managed to slightly debug the root cause of this problem with Visual Studio 2012 and Windows 7. It reproduces with Visual Studio 2012 (v110) platform toolset and Multi-threaded Debug (/MTd) option only (static CRT). It works (ie. no CRT leaks in the output) when setting either Multi-threaded Debug DLL (/MDd) option or Visual Studio 2010 (v100) platform toolset. When comparing what is happening inside vld code I can see that with the 2010 platform toolset VLD is setting the VLD_HEAP_CRT_DBG flag in _HeapCreate function because it is called from the _heap_init CRT function. This function calls HeapCreate which is captured by VLD. With the 2012 toolset the _heap_init CRT function does not call the HeapCreate API, but instead it uses GetProcessHeap() to get the process heap. And in this case VLD never sets the VLD_HEAP_CRT_DBG flag and outputs the CRT leaks. So somehow VLD would need to better distinguish which heap or call is coming from the CRT. I am using VLD v2.3.0. Also I believe this is a duplicate of https://vld.codeplex.com/workitem/10421
<p>Compile option /MTd.</p>
<p>Memory leak is reported with the next code.</p>
<p> </p>
<p>int _tmain(int argc, _TCHAR* argv[])</p>
<p>{</p>
<p> return 0;</p>
<p>}</p>
<p> </p>
<p>VisualLeakDetector::_HeapCreate() dose not seem to be called...</p>
<p> </p>
<p>*I use machine translation, I cannot express it well.</p>
Comments: I have managed to slightly debug the root cause of this problem with Visual Studio 2012 and Windows 7. It reproduces with Visual Studio 2012 (v110) platform toolset and Multi-threaded Debug (/MTd) option only (static CRT). It works (ie. no CRT leaks in the output) when setting either Multi-threaded Debug DLL (/MDd) option or Visual Studio 2010 (v100) platform toolset. When comparing what is happening inside vld code I can see that with the 2010 platform toolset VLD is setting the VLD_HEAP_CRT_DBG flag in _HeapCreate function because it is called from the _heap_init CRT function. This function calls HeapCreate which is captured by VLD. With the 2012 toolset the _heap_init CRT function does not call the HeapCreate API, but instead it uses GetProcessHeap() to get the process heap. And in this case VLD never sets the VLD_HEAP_CRT_DBG flag and outputs the CRT leaks. So somehow VLD would need to better distinguish which heap or call is coming from the CRT. I am using VLD v2.3.0. Also I believe this is a duplicate of https://vld.codeplex.com/workitem/10421
↧
Edited Issue: Static CRT leaks? [10446]
I use Visual Studio 2012 and VLD 2.2.3.
Compile option /MTd.
Memory leak is reported with the next code.
```
int _tmain(int argc, _TCHAR* argv[])
{
return 0;
}
```
VisualLeakDetector::_HeapCreate() dose not seem to be called...
*I use machine translation, I cannot express it well.
Compile option /MTd.
Memory leak is reported with the next code.
```
int _tmain(int argc, _TCHAR* argv[])
{
return 0;
}
```
VisualLeakDetector::_HeapCreate() dose not seem to be called...
*I use machine translation, I cannot express it well.
↧
New Post: Visual Studio 2013
Master branch support VS2013
↧
Source code checked in, #367d5721978b2b67ac02947a7140daf2e8ffef72
Memory leaks with static linked CRT fixed for VS2012/2013.
Called allocation function added to printed callstack.
↧
↧
New Post: Visual Studio 2013
Hi! Thanks a lot for your support!
I have just tried to download the code from GIT, compile it and create the installer but unfortunately it gives me the following error. I needed to recompile everything using Visual Studio 2013 as it is the only one I have installed... Not sure if that might cause any issue.
SpaceInvaders.exe - Error de la aplicación
La aplicación no se pudo iniciar correctamente (0xc0150002). Haga clic en Aceptar para cerrarla.
Aceptar
↧
New Post: Visual Studio 2013
Thank you KindDragon! I just compiled and tested, everything works great!
danilojose:
My app failed this way initially as it picked up the old version of the vld.dll, but I had linked against the new vld.lib.
Make sure you are linking on the new vld.lib and check in the Output pane that you are loading the correct vld dll.
danilojose:
My app failed this way initially as it picked up the old version of the vld.dll, but I had linked against the new vld.lib.
Make sure you are linking on the new vld.lib and check in the Output pane that you are loading the correct vld dll.
↧
New Post: Visual Studio 2013
Thank you KindDragon!!! We all love this software!
Will you be making a v2.4 installer? The setup\ directory uses Inno Setup 5 (which I've used before), but does not generate the same installer as v2.3. Namely, the .iss looks for the .dlls in the wrong directory and does not create the registry entries (mine had problems finding the .ini file). I really like that the .iss will modify the Visual Studio Win32.cpp property page to set the additional include\ & lib\ directories, though that should probably be optional.
Will you be making a v2.4 installer? The setup\ directory uses Inno Setup 5 (which I've used before), but does not generate the same installer as v2.3. Namely, the .iss looks for the .dlls in the wrong directory and does not create the registry entries (mine had problems finding the .ini file). I really like that the .iss will modify the Visual Studio Win32.cpp property page to set the additional include\ & lib\ directories, though that should probably be optional.
↧
Source code checked in, #647a6499181a3e81581a876b5dc06987d92878b9
VS project configuration fixed
↧
↧
Edited Issue: DLL CRT initialization leaks [10421]
When VLD is linked with a DLL, it reports quite some leaks in initialization routines. After some exploration, it seems that CRT allocates some memory to hold environment variables, argv etc. and does not bother to free them (since it is not needed as they live through whole lifetime of a module).
The problem is that these leak reports pollute debug output window possibly hiding any actual leaks in a library. Is it possible to hide them somehow? I tried to use VLDMarkAllLeaksAsReported at the beginning of DllMain function but it also hides all executable leaks before that (using LoadLibrary). I build against static CRT in VS 2008.
I leave this issue to a discussion as this behavior is technically correct (CRT actually leaks memory) but there should be a way to ignore these leaks as well as they are "by design".
Example output:
WARNING: Visual Leak Detector detected memory leaks!
Visual Leak Detector detected 54 memory leaks in heap 0x00D10000
---------- Block 62 at 0x00D10A30: 164 bytes ----------
Call Stack:
f:\dd\vctools\crt_bld\self_x86\crt\src\onexit.c (208): InstUp.dll!__onexitinit + 0x15 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c (953): InstUp.dll!_initterm_e + 0x7 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c (297): InstUp.dll!_cinit + 0xF bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (132): InstUp.dll!_CRT_INIT + 0x19 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (312): InstUp.dll!__DllMainCRTStartup + 0x11 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (281): InstUp.dll!_DllMainCRTStartup + 0x11 bytes
0x77329950 (File and line number not available): ntdll.dll!RtlQueryEnvironmentVariable + 0x241 bytes
0x7732D8C9 (File and line number not available): ntdll.dll!LdrResSearchResource + 0xB4D bytes
0x7733681C (File and line number not available): ntdll.dll!RtlGetNtVersionNumbers + 0x9B bytes
0x773352D6 (File and line number not available): ntdll.dll!RtlSetUnhandledExceptionFilter + 0x50 bytes
0x77329E79 (File and line number not available): ntdll.dll!LdrInitializeThunk + 0x10 bytes
Data:
D8 32 D1 00 00 00 00 00 2C 3D 52 50 D0 00 00 00 .2...... ,=RP....
80 00 00 00 02 00 00 00 3E 00 00 00 FD FD FD FD ........ >.......
10 3E E0 45 10 3E E0 45 10 3E E0 45 10 3E E0 45 .>.E.>.E .>.E.>.E
10 3E E0 45 10 3E E0 45 10 3E E0 45 10 3E E0 45 .>.E.>.E .>.E.>.E
10 3E E0 45 10 3E E0 45 10 3E E0 45 10 3E E0 45 .>.E.>.E .>.E.>.E
10 3E E0 45 00 00 00 00 00 00 00 00 00 00 00 00 .>.E.... ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
FD FD FD FD ........ ........
---------- Block 12 at 0x00D11F80: 67 bytes ----------
Call Stack:
f:\dd\vctools\crt_bld\self_x86\crt\src\stdenvp.c (127): InstUp.dll!_setenvp + 0x14 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (132): InstUp.dll!_CRT_INIT + 0xE bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (312): InstUp.dll!__DllMainCRTStartup + 0x11 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (281): InstUp.dll!_DllMainCRTStartup + 0x11 bytes
0x77329950 (File and line number not available): ntdll.dll!RtlQueryEnvironmentVariable + 0x241 bytes
0x7732D8C9 (File and line number not available): ntdll.dll!LdrResSearchResource + 0xB4D bytes
0x7733681C (File and line number not available): ntdll.dll!RtlGetNtVersionNumbers + 0x9B bytes
0x773352D6 (File and line number not available): ntdll.dll!RtlSetUnhandledExceptionFilter + 0x50 bytes
0x77329E79 (File and line number not available): ntdll.dll!LdrInitializeThunk + 0x10 bytes
Data:
78 1E D1 00 E0 1F D1 00 B0 71 52 50 7E 00 00 00 x....... .qRP~...
1F 00 00 00 02 00 00 00 0C 00 00 00 FD FD FD FD ........ ........
41 4C 4C 55 53 45 52 53 50 52 4F 46 49 4C 45 3D ALLUSERS PROFILE=
43 3A 5C 50 72 6F 67 72 61 6D 44 61 74 61 00 FD C:\Progr amData..
FD FD FD ........ ........
The problem is that these leak reports pollute debug output window possibly hiding any actual leaks in a library. Is it possible to hide them somehow? I tried to use VLDMarkAllLeaksAsReported at the beginning of DllMain function but it also hides all executable leaks before that (using LoadLibrary). I build against static CRT in VS 2008.
I leave this issue to a discussion as this behavior is technically correct (CRT actually leaks memory) but there should be a way to ignore these leaks as well as they are "by design".
Example output:
WARNING: Visual Leak Detector detected memory leaks!
Visual Leak Detector detected 54 memory leaks in heap 0x00D10000
---------- Block 62 at 0x00D10A30: 164 bytes ----------
Call Stack:
f:\dd\vctools\crt_bld\self_x86\crt\src\onexit.c (208): InstUp.dll!__onexitinit + 0x15 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c (953): InstUp.dll!_initterm_e + 0x7 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c (297): InstUp.dll!_cinit + 0xF bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (132): InstUp.dll!_CRT_INIT + 0x19 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (312): InstUp.dll!__DllMainCRTStartup + 0x11 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (281): InstUp.dll!_DllMainCRTStartup + 0x11 bytes
0x77329950 (File and line number not available): ntdll.dll!RtlQueryEnvironmentVariable + 0x241 bytes
0x7732D8C9 (File and line number not available): ntdll.dll!LdrResSearchResource + 0xB4D bytes
0x7733681C (File and line number not available): ntdll.dll!RtlGetNtVersionNumbers + 0x9B bytes
0x773352D6 (File and line number not available): ntdll.dll!RtlSetUnhandledExceptionFilter + 0x50 bytes
0x77329E79 (File and line number not available): ntdll.dll!LdrInitializeThunk + 0x10 bytes
Data:
D8 32 D1 00 00 00 00 00 2C 3D 52 50 D0 00 00 00 .2...... ,=RP....
80 00 00 00 02 00 00 00 3E 00 00 00 FD FD FD FD ........ >.......
10 3E E0 45 10 3E E0 45 10 3E E0 45 10 3E E0 45 .>.E.>.E .>.E.>.E
10 3E E0 45 10 3E E0 45 10 3E E0 45 10 3E E0 45 .>.E.>.E .>.E.>.E
10 3E E0 45 10 3E E0 45 10 3E E0 45 10 3E E0 45 .>.E.>.E .>.E.>.E
10 3E E0 45 00 00 00 00 00 00 00 00 00 00 00 00 .>.E.... ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
FD FD FD FD ........ ........
---------- Block 12 at 0x00D11F80: 67 bytes ----------
Call Stack:
f:\dd\vctools\crt_bld\self_x86\crt\src\stdenvp.c (127): InstUp.dll!_setenvp + 0x14 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (132): InstUp.dll!_CRT_INIT + 0xE bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (312): InstUp.dll!__DllMainCRTStartup + 0x11 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (281): InstUp.dll!_DllMainCRTStartup + 0x11 bytes
0x77329950 (File and line number not available): ntdll.dll!RtlQueryEnvironmentVariable + 0x241 bytes
0x7732D8C9 (File and line number not available): ntdll.dll!LdrResSearchResource + 0xB4D bytes
0x7733681C (File and line number not available): ntdll.dll!RtlGetNtVersionNumbers + 0x9B bytes
0x773352D6 (File and line number not available): ntdll.dll!RtlSetUnhandledExceptionFilter + 0x50 bytes
0x77329E79 (File and line number not available): ntdll.dll!LdrInitializeThunk + 0x10 bytes
Data:
78 1E D1 00 E0 1F D1 00 B0 71 52 50 7E 00 00 00 x....... .qRP~...
1F 00 00 00 02 00 00 00 0C 00 00 00 FD FD FD FD ........ ........
41 4C 4C 55 53 45 52 53 50 52 4F 46 49 4C 45 3D ALLUSERS PROFILE=
43 3A 5C 50 72 6F 67 72 61 6D 44 61 74 61 00 FD C:\Progr amData..
FD FD FD ........ ........
↧
Created Unassigned: COM object cannot be registered [10553]
I have a large solution contains many COM objects.
So, I have added vld.h to one of the COM projects to try to detect memory leaks.
After this VS2010 cannot register this COM after it is built.
I have removed include vld.h then VS successfully registered.
How I can solve this problem?
Thank you.
So, I have added vld.h to one of the COM projects to try to detect memory leaks.
After this VS2010 cannot register this COM after it is built.
I have removed include vld.h then VS successfully registered.
How I can solve this problem?
Thank you.
↧
New Post: endless recursive call to VLD itself
Can you provide more information?
OS version, VS version, static or dynamic CRT you use
Do you use Application Verifier?
OS version, VS version, static or dynamic CRT you use
Do you use Application Verifier?
↧