Work performed on various issues

[ioannis-e]

The highlights of the changes made are as follows:

• Install a hook on LdrpCallInitRoutine() or the relevant nt loader code to cover all Windows XP to Windows 10, x86 and x64 platforms in order to Refresh Modules before the dll entry point. The current implementation Refreshes the Modules after the dll entry point which in effect does not detect any allocations made on dll entry point.
• Fix #9519, #9859, #10544, use LoaderLock to serialize any calls which load additional libraries or require access to the Loader Lock.
• Fix #6359, #10553, fix crashes and failure to register COM dlls where Visual Leak Detector is unloaded before IMalloc interface is released.
• Optimize _GetProcAddress and _GetProcAddressForCaller to properly test for ordinal vs function name
• Append Visual Studio 2015/2013/2012/2010/2008 symbols cache directory where multiple VS versions are installed on the same system.
• Add option to skip reporting crt startup allocations as memory leaks
  • for debug runtime (where debug crt allocations are not properly identied) and
  • for release runtime (by excluding certain startup crt initialisation modules), this may have an effect in performance.
• Improve the vld.ini searching from additional locations listed below in order, and fix installer issue where it would not set the vld.ini path in registry for x64 platform:
  • current directory
  • directory where VLDDLL resides
  • directory where executable resides
  • path specified in registry HKCU
  • path specified in registry HKLM
• All other commits resolve compiler warnings and improvements to the code following PVS-Studio analysis.
• Clean up of solutions and project files
• Improvements and additions to test cases

I tried to keep commits independed of each other as much as possible, to make review easier.

I would suggest to cherypick as much as possible into master in order to rebase this PR and leave us with only the commits that need discussion.

[ioannis-e]

Do you want any changes made from this point on in one or more new commits or edit the relevant commits in place? What's best for review?

[KindDragon]

You can make changes in new commit and then rebase before we will merge this PR.

[ioannis-e]

Super, we lost the entire review because i had to rebase master due to 778a1e95803b30a3e0918348504455c7343a0cdb

In any case I have resolved the performance degradation issue. So you are good to go again.

[ioannis-e]

I'll have time this weekend to resolve any new review points so we can finally finish this. Only things left for me to do is:

• [x] merge review commits with original commits once you give me the ok
• [ ] run a 4 spaces formatting at the end, to have consistent code format. separate PR

[KindDragon]

Your code crash on x64 (Windows 10) when call FreeLibrary Exception thrown at 0x00007FF8870B3D6D (ntdll.dll) in vld_main.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

[KindDragon]

Please cheery pick this commit https://github.com/KindDragon/vld/commit/8d155b79a16177f35261a2a14bce3d7fce1e746f . Results with TestUnload - https://ci.appveyor.com/project/KindDragon/vld/build/71/job/2089w3s2taa31ltu/tests

[KindDragon]

and ComTest doesn't register on x64

[ioannis-e]

I have fixed

• crash on x64 (Windows 10) when call FreeLibrary
• ComTest doesn't register on x64
• vld_main additional CRT leaks on VS2015
• improvements to vld_unload test

[ioannis-e]

With the modification made to the project files, the vs14 solution is loadable in vs12, the only thing is that the platform should be changed within VS, I have made the platform a default setting for all configurations, so when it changes it changes for all configurations.

In this respect i guess we dont need to keep vs12 and vs14 solutions. Would you agree to remove the vs12 solutions and projects ?

[KindDragon]

Great work

Would you agree to remove the vs12 solutions and projects ?

I'm using VS12 solution to check vld with VS2013 toolset on local Teamcity. Therefore, it is still necessary to me.

[ioannis-e]

Ok, i'll keep them and i will make the solutions and projects the same appart from the toolset.

[ioannis-e]

Updated projects and solutions Added PerUserREdirection to ComTest Added StaticCrt to ComTest (lets see if anything else pops up on appveyor)

If there is nothing else, i am ready !

[ioannis-e]

Builds successfully again! So let me know how to proceed.

[KindDragon]

So everything is ok. If you have already done, I merge PR.

[ioannis-e]

Do you want me to squash any commits ? or leave them as they are ? I'll make another PR for source formatting

[ioannis-e]

The following should be resolved: https://vld.codeplex.com/workitem/10548 https://vld.codeplex.com/workitem/10588 https://vld.codeplex.com/workitem/10587

[KindDragon]

If not hard please squash commits that fix other commits like 53277cb with b491ca2be, 69f8936 with b38b1e0a88a7e, 3a8a03b53ff99dac with de78327c66aa190cd Please also add comment to de78327c66aa190cd why we should skip count CRT_USE_TYPE(crtheader->use) == CRT_USE_IGNORE

[ioannis-e]

OK ready to merge PR.

On a side note safe is not that much slower from fast

Environment: VldStackWalkMethod=safe; Configuration: Release; Platform: Win32  1 min 35 sec
Environment: VldStackWalkMethod=safe; Configuration: Release; Platform: x64    1 min 39 sec
Environment: VldStackWalkMethod=fast; Configuration: Release; Platform: Win32  1 min 24 sec
Environment: VldStackWalkMethod=fast; Configuration: Release; Platform: x64    1 min 22 sec

[KindDragon]

Appveyor runs vld_main in tests but it does not take into account the process exit code. Can you fix this, so the exit code is taken into account when running the tests ?

I'll try to think of something

[Trass3r]

Nice work!

[ioannis-e]

Thanks :+1: actually @KindDragon and his integration of AppVeyor helped a lot!!! Hopefully now @KindDragon can release a new version soon with a brand new number v2.½ :)

Also please delete any branches with obsolete code out there, just to be safe.

[KindDragon]

Hi @ioannis-e, I fix vld_main test for AppVeyor and it fail on x64 for Release? Can you look at it?

https://ci.appveyor.com/project/KindDragon/vld

[KindDragon]

I found what cause it. Win64 optimizer inline `dynamic initializer for '*''() call Debug:

vld_x64.dll!VisualLeakDetector::_HeapAlloc(void * heap, unsigned long flags, unsigned __int64 size) Line 1640   C++
ucrtbased.dll!heap_alloc_dbg_internal(const unsigned __int64 size, const int block_use, const char * const file_name, const int line_number) Line 359   C++
ucrtbased.dll!heap_alloc_dbg(const unsigned __int64 size, const int block_use, const char * const file_name, const int line_number) Line 450    C++
ucrtbased.dll!_malloc_dbg(unsigned __int64 size, int block_use, const char * file_name, int line_number) Line 492   C++
ucrtbased.dll!malloc(unsigned __int64 size) Line 22 C++
vld_x64.dll!VisualLeakDetector::_malloc(void * (unsigned __int64) * pmalloc, context_t & context, bool debugRuntime, unsigned __int64 size) Line 169    C++
vld_x64.dll!CrtPatch<130,1>::crtd_malloc(unsigned __int64 size) Line 431    C++
vld_main.exe!`dynamic initializer for 's_m''() Line 20  C++
ucrtbased.dll!_initterm(void (void) * * first, void (void) * * last) Line 22    C++
vld_main.exe!__scrt_common_main_seh() Line 232  C++
vld_main.exe!__scrt_common_main() Line 309  C++
vld_main.exe!wmainCRTStartup() Line 17  C++
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart()  Unknown

Release:

vld_x64.dll!VisualLeakDetector::_HeapAlloc(void * heap, unsigned long flags, unsigned __int64 size) Line 1640   C++
ucrtbase.dll!malloc()  Unknown
vld_x64.dll!CrtPatch<130,0>::crtd_malloc(unsigned __int64 size) Line 430    C++
ucrtbase.dll!_initterm()   Unknown
vld_main.exe!__scrt_common_main_seh() Line 232  C++
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart()  Unknown

[ioannis-e]

@KindDragon Thanks, i'll have a look as well over the weekend.

I am considering that maybe isCrtStartupModule is too agressive for VS2015 due to endWith(filename, len, L"\\crts\\ucrt\\src\\appcrt\\startup\\initterm.cpp") ||

I'll let you know when i run some tests.

By the way does VS2013 pass all tests ? I think we may need to add endWith(filename, len, L"\\crt\\crtw32\\startup\\tidtable.c") ||

PS: In my opinion the number of leaks is 9 for all configurations for both VS2013 and 2015 so the test shouldn't change..

PS2: In vld_main i suggest we use VLDSetOption to set VLD_OPT_TRACE_INTERNAL_FRAMES for all configurations it will make our life easier

[KindDragon]

By the way does VS2013 pass all tests ?

Yes, except Release_StaticCrt x64. It's return 7

[KindDragon]

I am considering that maybe isCrtStartupModule is too agressive for VS2015 due to endWith(filename, len, L"\crts\ucrt\src\appcrt\startup\initterm.cpp") ||

It does not help us, because we skip allocations from ucrtbase.dll (_initterm) which is excluded module

[KindDragon]

b8ff3b1915b7eadb6cca8633119ee7ec04d03a9c

[ioannis-e]

Actually this is how i would solve this 12cdc5ff036557658428a525ac6a510d6bf63818 85f60e85cce2740181b5a294cac31cfb7aa1b7f8 As i said we shouldn't modify vld_main_test

typedef CrtPatch<130> to typedef CrtPatch<140> really did the trick :)

AppVeyor for 12cdc5f AppVeyor for 85f60e8

[ioannis-e]

I also tested runalltests v120 with 85f60e85cce2740181b5a294cac31cfb7aa1b7f8 and all tests pass for VS 2013

[KindDragon]

A lot of issues with VS2013 toolset :-( https://ci.appveyor.com/project/KindDragon/vld

[ioannis-e]

I see, could you also try ioannis-e@85f60e85cce2740181b5a294cac31cfb7aa1b7f8 instead of b8ff3b1915b7eadb6cca8633119ee7ec04d03a9c ?

[KindDragon]

https://ci.appveyor.com/project/KindDragon/vld/build/97

[ioannis-e]

I am testing as well in my repo. https://ci.appveyor.com/project/ioannis-e/vld/build/3 i'd suggest to use a develop branch to test stuff to keep master clean?

[ioannis-e]

Appveyor: error MSB8020: The build tools for v110_xp (Platform Toolset = 'v110_xp') cannot be found. Maybe ask support how to install ?

Environment: VldStackWalkMethod=safe, Solution=vld_vs12.sln; Configuration: Release_StaticCrt; Platform: Win32

Seems to be deadlocking on appveyor but runs ok localy ...

[KindDragon]

Seems to be deadlocking on appveyor but runs ok localy ...

With StackWalkMethod safe?

[ioannis-e]

wait, let me test safe locally... and i'll report back

[ioannis-e]

Yes just run dynamic_app test with StackWalkMethod=safe and it runs ok locally, but deadlocks in appveyor. Can you run the same test as well ?

[ioannis-e]

https://ci.appveyor.com/project/ioannis-e/vld/build/3

So it only fails on vs12 Release_StaticCrt Win32/x64 in safe mode So how is the test different between vs14 and vs12 ?

[KindDragon]

Hang for me

[ioannis-e]

On which windows are you ?

[ioannis-e]

Can you add a LoaderLock ll; in SafeCallstack::getStackTrace

[KindDragon]

win 10

[KindDragon]

Works for me. Waiting for appveyor https://ci.appveyor.com/project/KindDragon/vld/build/99

[KindDragon]

Now Environment: VldStackWalkMethod=safe, Solution=vld_vs12.sln; Configuration: Debug_VldRelease_StaticCrt; Platform: Win32 hang

[KindDragon]

LdrLock deadlock with crt heap lock

[ioannis-e]

Damn, thread syncronisations don't work... i thought i got them working (back to the drawing board)

[ioannis-e]

See if you like ioannis-e@357f91a3afe8e9ae24908647fba6b5544db6db04 and whether it works for you as well ? https://ci.appveyor.com/project/ioannis-e/vld/build/7

I temporarily removed VS2012 appveyour tests since they kept failing. Can you build/run in VS2012/VS2010 at all ? I am interested to see whether vld_main_test and vld_unload exhibit different behaviour.

[KindDragon]

Can you build/run in VS2012/VS2010 at all ?

I can not configure build under VS2010

[ioannis-e]

I meant locally not on appveyor. I have VS2010 on x86, but the Batch Build... feature is broken, and i cannot test all configurations. I want to confirm that isCrtStartupModule() reports correctly in older versions.

Did you get any feedback from appveyor support regarding v110 toolset ?

[KindDragon]

I meant locally not on appveyor.

I meant this too