Quantcast
Channel: Visual Leak Detector for Visual C++ 2008-2015
Viewing all 704 articles
Browse latest View live

Closed Unassigned: LoadLibrary bug... [10555]

$
0
0
My English is not very good.
So instead sample code.

```
#include "vld.h"
#include <Windows.h>
#include <tchar.h>
#include <process.h>

UINT WINAPI ThreadProc1(LPVOID pParam)
{
while(1)
{
HMODULE hModule = ::LoadLibrary(_T("wtsapi32.dll"));

if(NULL != hModule)
{
::FreeLibrary(hModule);
hModule = NULL;
}
}

return 0;
}

UINT WINAPI ThreadProc2(LPVOID pParam)
{
while(1)
{
HMODULE hModule = ::LoadLibrary(_T("psapi.dll"));

if(NULL != hModule)
{
::FreeLibrary(hModule);
hModule = NULL;
}
}

return 0;
}

int main(int argc, char *argv[])
{
UINT nThreadID;
HANDLE hThread[2];

hThread[0] = (HANDLE)_beginthreadex(NULL, 0, ThreadProc1, NULL, 0, &nThreadID);
hThread[1] = (HANDLE)_beginthreadex(NULL, 0, ThreadProc2, NULL, 0, &nThreadID);

::WaitForMultipleObjects(2, hThread, TRUE, INFINITE);

return 0;
}

```



=> Crash Utility.cpp

```
IMAGE_IMPORT_DESCRIPTOR* FindOriginalImportDescriptor (HMODULE importmodule, LPCSTR exportmodulename)
{
IMAGE_IMPORT_DESCRIPTOR* idte = NULL;
IMAGE_SECTION_HEADER* section = NULL;
ULONG size = 0;

// Locate the importing module's Import Directory Table (IDT) entry for the
// exporting module. The importing module actually can have several IATs --
// one for each export module that it imports something from. The IDT entry
// gives us the offset of the IAT for the module we are interested in.
g_imageLock.Enter();
__try
{
___idte = (IMAGE_IMPORT_DESCRIPTOR*)ImageDirectoryEntryToDataEx((PVOID)importmodule, TRUE,
IMAGE_DIRECTORY_ENTRY_IMPORT, &size, &section);___
}
__except(FilterFunction(GetExceptionCode()))
{
idte = NULL;
}
...
}
```

New Post: VLD in Release mode

$
0
0
You can try with define VLD_FORCE_ENABLE

Source code checked in, #2c950e88ab23484a9680b04dcac590a6b7ee5da5

Source code checked in, #b5f982b63ae8c4bcf2aafd4c67d10e42da2fb586

Source code checked in, #008a187b2d099daf831a59a614ddd8ac86c0dfb2

$
0
0
_HeapReAlloc crash fixed after d84107cda2

Source code checked in, #ff9241dfd184bdeeb5062792a92db26f34b7239c

Source code checked in, #7d3a9d88d92e1dfb6bcbccbbba8f207676a4a110

$
0
0
%processor_architecture% check fixed

Source code checked in, #29aa7e61abda3369d06528fc789b8637c0d5713a

$
0
0
Release static linked CRT detection improved

Closed Unassigned: Dedpendency Walker message [10549]

$
0
0
When viewing a DLL which has VLD support through an '#include <vld.h>' Dependency Walker shows no problems. When viewing an EXE which has VLD support through an '#include <vld.h>' Dependency Walker gives me:

Error: The Side-by-Side configuration information for "c:\program files\visual leak detector\bin\win32\VLD_X86.DLL" contains errors. The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail (14001).

Comments: Dedpendency Walker show this message if it cant find dbghelp.dll

Commented Unassigned: vld.ini search path [10548]

$
0
0
In my setup loaded vld.dll is located in different from EXE directory.
Vld.ini is also stored near vld.dll but directory containing vld.dll isn't looked at.
Comments: You can set path to vld.ini in register HKCU\Software\Visual Leak Detector\IniFile

Closed Unassigned: Access Violation at startup [10547]

$
0
0
When launching an application using VLD, I get an access violation.
Already tried building VLD from source, and I get the same problem.
I remember happening before, and doing nothing special. Eventually started working again.
Today started crashing again, and I don't remember changing anything that could cause this.
Maybe something related to DLL loading order.

I've track down the problem to VOID VisualLeakDetector::RefreshModules(), line 1864.
It seems it tries to free resources from the old module list, when that list is null.
I could just put a check around that code and not try to do free the modules list, but probably that list shouldn't be empty at that point, and I'll be hiding the problem that causes it in the first place?

Call stack:
> vld_x64.dll!CriticalSection::Enter() Line 18 C++
vld_x64.dll!CriticalSectionLocker::CriticalSectionLocker(CriticalSection & cs) Line 54 C++
vld_x64.dll!Tree<moduleinfo_t>::begin() Line 149 C++
vld_x64.dll!Set<moduleinfo_t>::begin() Line 245 C++
vld_x64.dll!VisualLeakDetector::RefreshModules() Line 1864 C++
vld_x64.dll!VisualLeakDetector::_LdrLoadDllWin8(unsigned __int64 reserved, unsigned long * flags, unicodestring_t * modulename, void * * modulehandle) Line 1837 C++
KernelBase.dll!LoadLibraryExW() Unknown
user32.dll!_InitializeImmEntryTable() Unknown
user32.dll!_UserClientDllInitialize() Unknown
ntdll.dll!LdrpCallInitRoutine() Unknown
ntdll.dll!LdrpInitializeNode() Unknown
ntdll.dll!LdrpInitializeGraph() Unknown
ntdll.dll!LdrpInitializeGraph() Unknown
ntdll.dll!LdrpPrepareModuleForExecution() Unknown
ntdll.dll!LdrGetProcedureAddressForCaller() Unknown
KernelBase.dll!GetProcAddress() Unknown
vld_x64.dll!VisualLeakDetector::_RGetProcAddress(HINSTANCE__ * module, const char * procname) Line 1790 C++
vld_x64.dll!PatchImport(HINSTANCE__ * importmodule, moduleentry_t * module) Line 479 C++
vld_x64.dll!PatchModule(HINSTANCE__ * importmodule, moduleentry_t * patchtable, unsigned int tablesize) Line 560 C++
vld_x64.dll!VisualLeakDetector::attachToLoadedModules(Set<moduleinfo_t> * newmodules) Line 624 C++
vld_x64.dll!VisualLeakDetector::VisualLeakDetector() Line 252 C++
vld_x64.dll!`dynamic initializer for 'g_vld''() Line 60 C++
vld_x64.dll!_initterm(void (void) * * pfbegin, void (void) * * pfend) Line 894 C
vld_x64.dll!_cinit(int initFloatingPrecision) Line 303 C
vld_x64.dll!_CRT_INIT(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 127 C
vld_x64.dll!__DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 362 C
vld_x64.dll!_DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 332 C
ntdll.dll!LdrpCallInitRoutine() Unknown
ntdll.dll!LdrpInitializeNode() Unknown
ntdll.dll!LdrpInitializeGraph() Unknown
ntdll.dll!LdrpInitializeGraph() Unknown
ntdll.dll!LdrpInitializeProcess() Unknown
ntdll.dll!_LdrpInitialize() Unknown
ntdll.dll!LdrInitializeThunk() Unknown



Comments: Should be fixed in 2.4

Commented Unassigned: Filter frames from top of stack for STL, etc. [10543]

$
0
0
It's not useful to see frames such as these on the top of the stack:

```
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xmemory (44): UT_DW_USB3.exe!std::_Allocate<std::_Tree_nod<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::b
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xmemory (146): UT_DW_USB3.exe!std::allocator<std::_Tree_nod<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::b
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xtree (1384): UT_DW_USB3.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,st + 0x16 bytes
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xtree (1178): UT_DW_USB3.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,st + 0xA bytes
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xtree (510): UT_DW_USB3.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,st + 0xA bytes
e:\ccmaster\sdr\main\windows64\vc90\vc\include\map (104): UT_DW_USB3.exe!std::map<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>
```

If the leak is really a bug in Microsoft's std::map implementation, for instance, then it's up to Microsoft to fix that. So after reporting the bug I would like to ignore these leaks completely (also from the total # leaks and total bytes leaked at the end of the log).

On the other hand, if the leak is really caused by in user code which happens to use std::map, then I don't care about the details of how std::map is implemented. In that case I would like to filter the frames inside STL code from the log, just to make the log more concise.

So I guess really these are two separate but related requests.

This applies not only to STL but any standard library provided with MSVC (STL, MFC, ATL, etc.). Appropriate paths for these should be pre-configured if possible. It can also apply to a 3rdparty library (e.g. Qt, boost) which is provided by the user: in that case, the user must configure the path(s) for that 3rdparty library.
Comments: Almost always this is problem with deleting class that have std::map data member

Edited Unassigned: Even more duplicate aggregation [10542]

$
0
0
According to the docs
https://vld.codeplex.com/wikipage?title=Configuration%20Options&referringTitle=Documentation

"AggregateDuplicates ... will make VLD aggregate all leaks that share the same size and call stack"

Even with this option set, I still get a very big logfile (1230 unique call stacks). I would like to have the possibility to enable even more aggressive behaviour to reduce the duplicates. [Of course this behaviour can be controlled by one or more options in vld.ini]

Here are some suggestions how to do it:

1) Don't require same size of allocation to aggregate.

2) Allow fuzzy rather than exact matching of call-stack for "similar" leaks.
Example:

```
void init() {
leaky("foo");
leaky("bar");
return 0;
}
void leaky(const char * const s) {
strdup(s);
}
```

In this example the line number for init() will be different between the two call stacks, but everything else is identical (and in fact the cause of the leak is the same).

Ideally we would like ALL calls to leaky(...) aggregated as a single log entry, but in practice it might be hard to do this without sometimes grouping really unique leaks as duplicate. A "fuzziness" parameter is definitely required.

3) Allow fuzzy matching even with macro-written code.
Example:

```
#define DEF_LEAKY(NAME) \
struct NAME { \
NAME() { strdup(#NAME); } \
};

DEF_LEAKY(Foo)
DEF_LEAKY(Bar)
void init()
{
Foo f;
Bar b;
}
```

In this example both the function (c'tor) names and line numbers at the top frame of the call stack are different e.g. Foo::Foo() vs Bar::Bar(), but really they are duplicates of the same leak as in 2.

Actually I think 3 is just a special case of 2, but I would like to mention it explicitly as this happens rather often in my real-world code. In this real-world example, the thing which is always identical is the offset, e.g. Foo::Foo + 0x1A bytes / Bar::Bar + 0x1A bytes. It's always 0x1A bytes.

Closed Unassigned: Compilation error for Visual Studio 2012 under Windows 8 [10541]

$
0
0
Hi,

I am using Visual Studio 2012 Ultimate under Windows 8. I used to use VLD for Visual Studio 2008 under Windows 7 without any problem.

But, now I get compilation errors when I try to use it in any project:
1>C:\Program Files (x86)\Windows Kits\8.0\Include\um\winuser.h(14958): error C2059: syntax error : ')'
1>C:\Program Files (x86)\Windows Kits\8.0\Include\um\winuser.h(14980): error C2059: syntax error : ')'

I downloaded the source code and compile it with my own compiler (no problem). Still, I have above problems. Do you have any suggestion ?

Commented Issue: VLD with application ends immediately with return code of 0xC0000417 [10538]

$
0
0
I am working with an application and a number of DLLs created in Visual Studio 2010. After adding vld.h to a single source file in the main application and all the DLLs, when I try to run the application it ends, after all the dllls are loaded, with a return code of 0xC0000417. It does not enter the InitInstance of the application at all. I have no idea why the application would fail with VLD.

Without VLD the application runs correctly.


Comments: Try copy vld and dbghelp.dll with manifest to your app directory

Edited Issue: error C2065: 'NtQueryInformationThread' : undeclared identifier [10534]

$
0
0
vs2010
XP Pro 2002 SP3

I get the following compilation errors
```
1>d:\projs\tools\visual leak detector\src\utility.cpp(937): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>d:\projs\tools\visual leak detector\src\utility.cpp(937): error C2146: syntax error : missing ';' before identifier 'ThreadBasicInformation'
1>d:\projs\tools\visual leak detector\src\utility.cpp(937): error C2065: 'ThreadBasicInformation' : undeclared identifier
1>d:\projs\tools\visual leak detector\src\utility.cpp(937): error C2143: syntax error : missing ';' before 'constant'
1>d:\projs\tools\visual leak detector\src\utility.cpp(939): error C2143: syntax error : missing ')' before '__stdcall'
1>d:\projs\tools\visual leak detector\src\utility.cpp(939): error C2059: syntax error : ')'
1>d:\projs\tools\visual leak detector\src\utility.cpp(943): error C2146: syntax error : missing ';' before identifier 'NtQueryInformationThread'
1>d:\projs\tools\visual leak detector\src\utility.cpp(943): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>d:\projs\tools\visual leak detector\src\utility.cpp(943): error C2065: 'NtQueryInformationThread' : undeclared identifier
1>d:\projs\tools\visual leak detector\src\utility.cpp(947): error C2065: 'NtQueryInformationThread' : undeclared identifier
1>d:\projs\tools\visual leak detector\src\utility.cpp(951): error C2065: 'NtQueryInformationThread' : undeclared identifier
1>d:\projs\tools\visual leak detector\src\utility.cpp(951): error C2146: syntax error : missing ';' before identifier 'GetProcAddress'
1>d:\projs\tools\visual leak detector\src\utility.cpp(954): error C2065: 'NtQueryInformationThread' : undeclared identifier
1>d:\projs\tools\visual leak detector\src\utility.cpp(959): error C2065: 'ThreadBasicInformation' : undeclared identifier
1>d:\projs\tools\visual leak detector\src\utility.cpp(959): error C3861: 'NtQueryInformationThread': identifier not found
```

the reason is that <winternl.h> is not included.

This happens because my SDK as updated by vs2010
```
c:\program files\microsoft sdks\windows\v7.0a\include\sdkddkver.h (line 197)
defines _WIN32_WINNT 0x0601 :

#if !defined(_WIN32_WINNT) && !defined(_CHICAGO_)
#define _WIN32_WINNT 0x0601
#endif
```

while stdafx.h does:
```
#if _WIN32_WINNT < 0x0600 // Windows XP or earlier, no GetProcessIdOfThread()
#include <winternl.h>
#endif
```

I simply had to modify 0x0600 -> 0x0602

I reported this but mostly for documentation
so other people having the same issue may easily know the reason.

Edited Issue: Compile issues when including vld.h with some project settings [10533]

$
0
0
I tried to use vld with two public domain libraries, ICU and sqlite. In both cases including vld.h caused compile/build errors.

For ICU the /Za option (disable VC++ extensions) is turned on, which causes a bunch of errors when including windows.h. This was easy to get around using the __STDC__ macro defined when using /Za:
```
#ifdef __STDC__
#define CONST const
typedef int BOOL
...
#else
#include
#endif
```

For sqlite, the problem was that it is built with the C compiler, not C++, and the "wchar_t" data type used in vld_def.h didn't seem to be defined. So I just changed the function signature to accept an "unsigned short *" as the second argument instead of "wchar_t *" (which should be equivalent).

I think it should be possible to incorporate both of these changes without negatively impacting other projects.

In both cases, once I got past these minor issues VLD worked perfectly. Thanks!

Edited Issue: Direct3D and DXUT in DLL [10481]

$
0
0
When I put code of EmptyProject10 from DirectX SDK (June 2010) into DLL the VLD don?t show any report. This issue seems to be caused by calling DXUTCreateDevice inside DLL project. When DXUTCreateDevice is commented in code, then VLD works fine.

I use VLD 2.2.3 (15 Febrary 2012), VS 2010 SP1, Windows 7 64 Pro

See attachment.

Closed Issue: VLD crashes in WIndows 8 [10393]

$
0
0
<p>hi!</p>
<p>I use windows 8, and use VS 2010 and vld 2.2.3.</p>
<p>but when vld runs, it crashes.</p>
<p>When I used windows 7, no problem found.</p>
<p>What&#39;s wrong with me?</p>

Comments: Should be fixed in 2.4

Edited Issue: VLDSetModulesList or VLDDisable also can not block a madule warning. [10378]

$
0
0
Hi
I'm using VLD on a project that is using Microsoft DirectX, In my report there are several report that show following warning:
WARNING: Visual Leak Detector: A module, d3dcompiler_43.dll, included in memory leak detection
does not have any debugging symbols available, or they could not be located.
Function names and/or line numbers for this module may not be available.

Its some days that i'm trying to exclude the warning or the d3dcompiler_43.dll but i'm not success.
How can i filter this warning?
Thank you for any help.

Viewing all 704 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>