Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ReportGenerator.exe consumes all available physical memory #251

Closed
gitlavir opened this issue Jun 4, 2019 · 4 comments
Closed

ReportGenerator.exe consumes all available physical memory #251

gitlavir opened this issue Jun 4, 2019 · 4 comments
Labels

Comments

@gitlavir
Copy link

gitlavir commented Jun 4, 2019

Hi,

I have an issue where calling ReportGenerator.exe on a .coveragexml file consumes as much physical memory as is available and sometimes throws an OutOfMemory exception.

The code-under-test is unmanaged C++ and unit-tested in MSVS 2017 using the CppUnitTestFramework with GMock via NuGet. Tests are executed using MSVS2017 Enterprise vstest.console.exe (/logger:trx /InIsolation /EnableCodeCoverage) with some coverage filters applied at compile time.

The .coverage output is converted to a .coveragexml using CodeCoverage.exe. The coveragexml file is small in size (1.35 MB) and is 13370 lines. ReportGenerator.exe is then invoked via command line as such:

C:\ReportGenerator\ReportGenerator.exe -reports:vstest.coveragexml "-targetdir:C:\Users\TestUser\CoverageReport" -reporttypes:Badges;Html "-historydir:C:\historydir" -tag:0.0.0.1

At this point the coveragexml is loaded and ReportGenerator.exe consumes all RAM. I have tested this on a Windows7 VM with 8 and 16GB RAM, as well as a Windows10 physical machine with 32GB. In all cases ReportGenerator.exe uses all available RAM, and occasionally throws an OutOfMemory exception. If it does succeed, the log shows 5 assembly dlls and 264 classes which is accurate.

Any help or guidance would be appreciated. Thanks!

@danielpalme
Copy link
Owner

danielpalme commented Jun 4, 2019

Can you share the .coveragexml file?
I would like to debug that on my system.

@gitlavir
Copy link
Author

gitlavir commented Jun 4, 2019

Unfortunately I can't share the .coveragexml file as the code is proprietary, but I've done some experiments and found that the behavior is caused by differences in MSVS 2015 vs 2017.

The .coveragexml files are nearly identical, but the 2017 version has an addition range source entry (example, in bold below):
ranges
range source_id="10" covered="yes" start_line="763" start_column="0" end_line="763" end_column="0"
range source_id="10" covered="yes" start_line="764" start_column="0" end_line="764" end_column="0"
range source_id="10" covered="yes" start_line="766" start_column="0" end_line="766" end_column="0"
range source_id="10" covered="yes" start_line="767" start_column="0" end_line="767" end_column="0"
range source_id="10" covered="yes" start_line="15732480" start_column="0" end_line="15732480" end_column="0"
/ranges

Decimal 15732480 is 0xF00F00, which is a special line number
#define _DEBUGGER_STEP_OVER 15732479 // 0xf00f00 - 1

Similarly, 16707565 is 0xFEEFEE, which is also a special line number though I have not seen it in a .coveragexml file.
#define _DEBUGGER_STEP_INTO 16707565 // 0xfeefee - 1

Using a small test dll, I generated a .coveragexml and manually stripped out lines containing 15732480, and ReportGenerator functioned normally.

As to why this happens, the only answer I can come up with is that MSVS2017 requires Linker Generate Debug Info /DEBUG:FULL for Code Coverage analysis, while 2015 does not (/DEBUG:FULL does not exist in 2015 at all). Other than Windows SDK Version and Platform Toolset, no other project or filter configuration changes were made when changing between versions.

Would it be possible for the ReportGenerator to strip out/ignore lines containing 15732480?

@danielpalme
Copy link
Owner

Thanks for investigating!

Could you please try this new release:
https://www.nuget.org/packages/ReportGenerator/4.1.10

@gitlavir
Copy link
Author

gitlavir commented Jun 5, 2019

I have tested the latest release and this issue has been fixed. Thank you for your fast response!

@gitlavir gitlavir closed this as completed Jun 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants