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

testhost.x86.exe should be able to handle large addresses. #834

Closed
harshjain2 opened this issue May 26, 2017 · 6 comments
Closed

testhost.x86.exe should be able to handle large addresses. #834

harshjain2 opened this issue May 26, 2017 · 6 comments

Comments

@harshjain2
Copy link
Contributor

Description

There could be scenarios where testhost.x86.exe requires more than 2 GB of memory. In those cases, current testhost.x86.exe could fail with StackOverFlowException/OutOfMemoryException as 32-bit programs receive only 2 GB of address space.

We should consider using /LARGEADDRESSAWARE flag in testhost.x86.exe.
When this flag is used while compiling, testhost.x86.exe can use up to 4GB of address space.

We also need to investigate the same has to be applied in DataCollector.exe and vstest.console.exe as well.

@harshjain2
Copy link
Contributor Author

@Faizan2304
Copy link
Contributor

Faizan2304 commented Jul 13, 2017

Current Status:

Currently dotnet tooling doesn't have support to use /LARGEADDRESSAWARE for cross plat. See related issue in compiler.

Workaround:

User can run their test for platform x64.

Action:

Moving this bug from milestone 15.5 and will address once the above issue will get fixed.

@Faizan2304 Faizan2304 removed this from the 15.5 (Sprint 121) milestone Jul 13, 2017
@Faizan2304 Faizan2304 removed their assignment Jul 13, 2017
@sharwell
Copy link
Member

sharwell commented Sep 22, 2017

@Faizan2304 The required compiler feature is already implemented going back to the first VS2015 release. It's just really sneaky. See my comment in the linked issue. 😄

@ghost
Copy link

ghost commented May 31, 2019

this appears to have been fixed in VS 2019
unknown

@sharwell
Copy link
Member

sharwell commented May 31, 2019

Weird. I refiled this as #1985 and then fixed it in #1986.

Weird because I commented in this issue, so I have no excuse for not knowing about its existence earlier. 😆

@singhsarab
Copy link
Contributor

@sharwell Cool! Thanks.
@fifthgearonline Thanks for confirmation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants