I've been using VLD 2.4RC2 for a while without too much trouble. However, occasionally my program would hang in GetOpenFileName(), but only when VLD was enabled/loaded. I found a comment from someone that they had this problem and it went away with VLD 2.5.
However, after installing VLD 2.5, suddenly a lot of my DLLs seem to be loading incorrectly somehow. Display is affected, embedded browser (chromium) stopped working (and hangs, actually), just basically all kind of things start working badly/differently.
When I enable exceptions in VS 2013, I find that VLD is generating addresses in FindRealCode() that don't exist in any module's code space - they are off in never never land somewhere. By default, for some reason this is allowed - I had to explicitly set my exceptions to stop for BAD_ACCESS (0xc0000005, I think) in order to see the error happen.
Looking at the actual memory, there is a JMP instruction (0xE9), followed by an offset that is way out of the modules address space (offset is 0xea000027). Once you add the address+offset, it points to a non-existent space between loaded modules. I checked to see if it was a signed/unsigned problem, but making it unsigned just makes it point to another unmapped space, after the module rather than before it. Not sure if it is relevant, but after the offset, the next two four byte values are 0xeb000027 and 0x30000027. Just seemed odd that those values were so similar. Also, looking at the original address from the code line:
LPVOID func = FindRealCode((LPVOID)thunk->u1.Function);
the value in thunk->u1.Function seems to point into an area containing static variables (.bdata in COFF, I think?).
Note that the crash/broken behavior happens with VLD disabled on startup - haven't tried enabling it from the getgo yet.
This is all on Win7 Pro, running on a x64 system, all under VS 2013 (and VLD rebuilt with 2013 for testing). Re-compiling VLD from scratch didn't seem to help (and somebody might want to update the build instructions when they get a Round Tuit). If it matters, the DLL's being loaded are wxWidgets, being loaded from wxPython, being loaded from Python, being loaded from the app.
However, after installing VLD 2.5, suddenly a lot of my DLLs seem to be loading incorrectly somehow. Display is affected, embedded browser (chromium) stopped working (and hangs, actually), just basically all kind of things start working badly/differently.
When I enable exceptions in VS 2013, I find that VLD is generating addresses in FindRealCode() that don't exist in any module's code space - they are off in never never land somewhere. By default, for some reason this is allowed - I had to explicitly set my exceptions to stop for BAD_ACCESS (0xc0000005, I think) in order to see the error happen.
Looking at the actual memory, there is a JMP instruction (0xE9), followed by an offset that is way out of the modules address space (offset is 0xea000027). Once you add the address+offset, it points to a non-existent space between loaded modules. I checked to see if it was a signed/unsigned problem, but making it unsigned just makes it point to another unmapped space, after the module rather than before it. Not sure if it is relevant, but after the offset, the next two four byte values are 0xeb000027 and 0x30000027. Just seemed odd that those values were so similar. Also, looking at the original address from the code line:
LPVOID func = FindRealCode((LPVOID)thunk->u1.Function);
the value in thunk->u1.Function seems to point into an area containing static variables (.bdata in COFF, I think?).
Note that the crash/broken behavior happens with VLD disabled on startup - haven't tried enabling it from the getgo yet.
This is all on Win7 Pro, running on a x64 system, all under VS 2013 (and VLD rebuilt with 2013 for testing). Re-compiling VLD from scratch didn't seem to help (and somebody might want to update the build instructions when they get a Round Tuit). If it matters, the DLL's being loaded are wxWidgets, being loaded from wxPython, being loaded from Python, being loaded from the app.