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

Source code checked in, #9868016c30dc78512569e37b567fc9e086a1a810

$
0
0
Merge pull request #8 from ioannis-e/ioannis Work performed on various issues

Source code checked in, #83585888e66186c0d4367bcc348d3a2e6adb7ea1

Source code checked in, #c4c877049191ec97a4c4ccd8858f9b0454d7b1dd

Source code checked in, #b8ff3b1915b7eadb6cca8633119ee7ec04d03a9c

$
0
0
VS2013/2015 VLD Main leaks count fixed

Source code checked in, #41bd39244a0bcf033bb09925b923b8da4172a05d

$
0
0
Fix for FindRealCode function in Win64 by @Ghoort

Source code checked in, #a58c068f0231add11cddd6e2fffc02edc8434584

Source code checked in, #211573edfda2da4a1b90487b51c6a81c2f88954b

$
0
0
Fix crt leaks detection for all configurations

New Post: VLD for Visual C++ 2015?

$
0
0
I see you have pushed some commits for support 2015. Cloned the repository and built it myself and use it in our project. As far as I can tell it works great! Have helped us solve some problems.
Keep up the good work!

New Post: VLD for Visual C++ 2015?

$
0
0
renglund wrote:
I see you have pushed some commits for support 2015. Cloned the repository and built it myself and use it in our project. As far as I can tell it works great! Have helped us solve some problems.
Keep up the good work!
I was wondering if you can upload your build because I don't have all the SDKs installed...
Appreciate it.

Source code checked in, #ad0d2795b9fe5dd080931443805cc6f04b77fd88

$
0
0
Fix building with source path with spaces Copy test dependencies prior to the build

New Post: VLD for Visual C++ 2015?

$
0
0
YunHsiao wrote:
renglund wrote:
I see you have pushed some commits for support 2015. Cloned the repository and built it myself and use it in our project. As far as I can tell it works great! Have helped us solve some problems.
Keep up the good work!
I was wondering if you can upload your build because I don't have all the SDKs installed...
Appreciate it.
I did it myself, thanks though, it works great.

New Post: VLD for Visual C++ 2015?

$
0
0
Which SDKs did you guys install to build VLD for VS 2015?

Thanks.

Created Unassigned: VLD Bug? [10589]

$
0
0
When I use VLD in my a dll, and I build a test project,then I use a interface function in the dll,and build the test projet.it prompt:
"WARNING: Visual Leak Detector: A module, test.exe, 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.
WARNING: Visual Leak Detector: A module, base_d.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.“
and the memory leak code in test project is not deletected!!!Not print the leak info in debug output and
file.The reason is VisualLeakDetector::~VisualLeakDetector function is not called. Why?

Created Unassigned: Stack overflow when TLS slot >= 64 and allocate memory in new thread [10590]

$
0
0
In short, Stack overflow when TLS slot >= 64 and allocate memory in new thread

Windows by default has 64 TLS slots. When you need more than 64, Windows will allocate expansion slots for each thread in the invocation to TLS related functions. This TLS expansion calls RtlAllocateHeap to allocate memory. RtlAllocateHeap has been hooked by VLD to trace memory allocation, which calls getTls() in VLD along the call chain.

However, Windows only expand TLS for current thread when needed. When a newly created thread tries to allocate memory, VLD will kicks in to trace allocation. When VLD gets a slot >= 64, results in a TLS expansion. Expansion tries to allocate memory, but calls back to VLD, which will use TLS to trace memory allocation. Thus, infinite loops occurs.

*To workaround this problem*, you can load VLD ASAP when Maxwell starts so it will get a TLS slot <64.

For a detailed explanation of Windows TLS internals, please refer to [Thread Local Storage, part 2: Explicit TLS](http://www.nynaeve.net/?p=181).

```
#include <windows.h>
#include <process.h>

void run(void *) {
void *ptr = malloc(100);
free(ptr);
}

int main(int argc, wchar_t *argv[]) {
for (int i = 0; i < 0x40; ++i) {
DWORD slot = TlsAlloc();
}

::LoadLibraryA("load_vld.dll");
::_beginthread(run, 0, NULL);

::Sleep(1000);

return 0;
}

```

Edited Unassigned: Stack overflow when VLD TLS slot >= 64 and allocate memory in new thread [10590]

$
0
0
In short, Stack overflow when VLD TLS slot >= 64 and allocate memory in new thread.

Windows by default has 64 TLS slots. When you need more than 64, Windows will allocate expansion slots for each thread in the invocation to TLS related functions. This TLS expansion calls RtlAllocateHeap to allocate memory. RtlAllocateHeap has been hooked by VLD to trace memory allocation, which calls getTls() in VLD along the call chain.

However, Windows only expand TLS for current thread when needed. When a newly created thread tries to allocate memory, VLD will kicks in to trace allocation. When VLD gets a slot >= 64, results in a TLS expansion. Expansion tries to allocate memory, but calls back to VLD, which will use TLS to trace memory allocation. Thus, infinite loops occurs.

*To workaround this problem*, you can load VLD ASAP when Maxwell starts so it will get a TLS slot <64.

For a detailed explanation of Windows TLS internals, please refer to [Thread Local Storage, part 2: Explicit TLS](http://www.nynaeve.net/?p=181).

```
#include <windows.h>
#include <process.h>

void run(void *) {
void *ptr = malloc(100);
free(ptr);
}

int main(int argc, wchar_t *argv[]) {
for (int i = 0; i < 0x40; ++i) {
DWORD slot = TlsAlloc();
}

::LoadLibraryA("load_vld.dll");
::_beginthread(run, 0, NULL);

::Sleep(1000);

return 0;
}

```

Edited Unassigned: Stack overflow when VLD TLS slot >= 64 and allocate memory in new thread [10590]

$
0
0
In short, Stack overflow when VLD TLS slot >= 64 and allocate memory in new thread.

Windows by default has 64 TLS slots. When you need more than 64, Windows will allocate expansion slots for each thread in the invocation to TLS related functions. This TLS expansion calls RtlAllocateHeap to allocate memory. RtlAllocateHeap has been hooked by VLD to trace memory allocation, which calls getTls() in VLD along the call chain.

However, Windows only expand TLS for current thread when needed. When a newly created thread tries to allocate memory, VLD will kicks in to trace allocation. When VLD gets a slot >= 64, results in a TLS expansion. Expansion tries to allocate memory, but calls back to VLD, which will use TLS to trace memory allocation. Thus, infinite loops occurs.

How VLD gets a TLS slot >= 64? It is loaded when there are more than 64 slots already.

*To workaround this problem*, you can load VLD ASAP when Maxwell starts so it will get a TLS slot <64.

For a detailed explanation of Windows TLS internals, please refer to [Thread Local Storage, part 2: Explicit TLS](http://www.nynaeve.net/?p=181).

```
#include <windows.h>
#include <process.h>

void run(void *) {
void *ptr = malloc(100);
free(ptr);
}

int main(int argc, wchar_t *argv[]) {
for (int i = 0; i < 0x40; ++i) {
DWORD slot = TlsAlloc();
}

::LoadLibraryA("load_vld.dll");
::_beginthread(run, 0, NULL);

::Sleep(1000);

return 0;
}

```

Edited Unassigned: Stack overflow when VLD TLS slot >= 64 and allocate memory in new thread [10590]

$
0
0
In short, Stack overflow when VLD TLS slot >= 64 and allocate memory in new thread.

Windows by default has 64 TLS slots. When you need more than 64, Windows will allocate expansion slots for each thread in the invocation to TLS related functions. This TLS expansion calls RtlAllocateHeap to allocate memory. RtlAllocateHeap has been hooked by VLD to trace memory allocation, which calls getTls() in VLD along the call chain.

However, Windows only expand TLS for current thread when needed. When a newly created thread tries to allocate memory, VLD will kicks in to trace allocation. When VLD gets a slot >= 64, results in a TLS expansion. Expansion tries to allocate memory, but calls back to VLD, which will use TLS to trace memory allocation. Thus, infinite loops occurs.

How VLD gets a TLS slot >= 64? It is loaded when there are more than 64 slots already.

*To workaround this problem*, you can load VLD ASAP when Maxwell starts so it will get a TLS slot <64.

For a detailed explanation of Windows TLS internals, please refer to [Thread Local Storage, part 2: Explicit TLS](http://www.nynaeve.net/?p=181).

```
#include <windows.h>
#include <process.h>

void run(void *) {
void *ptr = malloc(100);
free(ptr);
}

int main(int argc, wchar_t *argv[]) {
for (int i = 0; i < 0x40; ++i) {
DWORD slot = TlsAlloc();
}

// note: load_vld.dll is another DLL load VLD. Don't load it directly.
::LoadLibraryA("load_vld.dll");
::_beginthread(run, 0, NULL);

::Sleep(1000);

return 0;
}

```

Edited Unassigned: Stack overflow when VLD Indirectly Loaded with TLS slot >= 64 and allocate memory in new thread [10590]

$
0
0
In short, Stack overflow when VLD is loaded indirectly with TLS slot >= 64 and allocate memory in new thread.

Windows by default has 64 TLS slots. When you need more than 64, Windows will allocate expansion slots for each thread in the invocation to TLS related functions. This TLS expansion calls RtlAllocateHeap to allocate memory. RtlAllocateHeap has been hooked by VLD to trace memory allocation, which calls getTls() in VLD along the call chain.

However, Windows only expand TLS for current thread when needed. When a newly created thread tries to allocate memory, VLD will kicks in to trace allocation. When VLD gets a slot >= 64, results in a TLS expansion. Expansion tries to allocate memory, but calls back to VLD, which will use TLS to trace memory allocation. Thus, infinite loops occurs.

How VLD gets a TLS slot >= 64? It is loaded when there are more than 64 slots already.

*To workaround this problem*, you can load VLD ASAP when Maxwell starts so it will get a TLS slot <64.

For a detailed explanation of Windows TLS internals, please refer to [Thread Local Storage, part 2: Explicit TLS](http://www.nynaeve.net/?p=181).

```
#include <windows.h>
#include <process.h>

void run(void *) {
void *ptr = malloc(100);
free(ptr);
}

int main(int argc, wchar_t *argv[]) {
for (int i = 0; i < 0x40; ++i) {
DWORD slot = TlsAlloc();
}

// note: load_vld.dll is another DLL load VLD. Don't load it directly.
::LoadLibraryA("load_vld.dll");
::_beginthread(run, 0, NULL);

::Sleep(1000);

return 0;
}

```

Edited Unassigned: Stack overflow when VLD gets TLS slot >= 64 and allocate memory in new thread [10590]

$
0
0
In short, Stack overflow when VLD gets TLS slot >= 64 and allocate memory in new thread.

Windows by default has 64 TLS slots. When you need more than 64, Windows will allocate expansion slots for each thread in the invocation to TLS related functions. This TLS expansion calls RtlAllocateHeap to allocate memory. RtlAllocateHeap has been hooked by VLD to trace memory allocation, which calls getTls() in VLD along the call chain.

However, Windows only expand TLS for current thread when needed. When a newly created thread tries to allocate memory, VLD will kicks in to trace allocation. When VLD gets a slot >= 64, results in a TLS expansion. Expansion tries to allocate memory, but calls back to VLD, which will use TLS to trace memory allocation. Thus, infinite loops occurs.

How VLD gets a TLS slot >= 64? It is loaded when there are more than 64 slots already.

*To workaround this problem*, you can load VLD ASAP when Maxwell starts so it will get a TLS slot <64.

For a detailed explanation of Windows TLS internals, please refer to [Thread Local Storage, part 2: Explicit TLS](http://www.nynaeve.net/?p=181).

```
#include <windows.h>
#include <thread>
#include <chrono>
#include <memory>

int main(int argc, wchar_t *argv[]) {
for (int i = 0; i < 0x40; ++i)
TlsAlloc();

HMODULE h_vld = LoadLibraryA("vld.dll");
typedef void(*vld_enable_t)(void);
auto vld_enable = (vld_enable_t)::GetProcAddress(h_vld, "VLDGlobalEnable");
vld_enable();
std::thread([]() {std::make_shared<int>(); }).join();
return 0;
}
```

Edited Unassigned: Stack overflow when VLD gets TLS slot >= 64 and allocate memory in new thread [10590]

$
0
0
In short, Stack overflow when VLD gets TLS slot >= 64 and allocate memory in new thread.

Windows by default has 64 TLS slots. When you need more than 64, Windows will allocate expansion slots for each thread in the invocation to TLS related functions. This TLS expansion calls RtlAllocateHeap to allocate memory. RtlAllocateHeap has been hooked by VLD to trace memory allocation, which calls getTls() in VLD along the call chain.

However, Windows only expand TLS for current thread when needed. When a newly created thread tries to allocate memory, VLD will kicks in to trace allocation. When VLD gets a slot >= 64, results in a TLS expansion. Expansion tries to allocate memory, but calls back to VLD, which will use TLS to trace memory allocation. Thus, infinite loops occurs.

How VLD gets a TLS slot >= 64? It is loaded when there are more than 64 slots already.

*To workaround this problem*, you can load VLD ASAP when application starts so it will get a TLS slot <64.

For a detailed explanation of Windows TLS internals, please refer to [Thread Local Storage, part 2: Explicit TLS](http://www.nynaeve.net/?p=181).

```
#include <windows.h>
#include <thread>
#include <chrono>
#include <memory>

int main(int argc, wchar_t *argv[]) {
for (int i = 0; i < 0x40; ++i)
TlsAlloc();

HMODULE h_vld = LoadLibraryA("vld.dll");
typedef void(*vld_enable_t)(void);
auto vld_enable = (vld_enable_t)::GetProcAddress(h_vld, "VLDGlobalEnable");
vld_enable();
std::thread([]() {std::make_shared<int>(); }).join();
return 0;
}
```
Viewing all 704 articles
Browse latest View live


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