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

Fix the Out-Of-Memory issues when running all tests from solution #3405

Closed
mansellan opened this issue Sep 30, 2017 · 5 comments

Comments

@mansellan
Copy link
Member

commented Sep 30, 2017

Currently, when running all Rubberduck tests, OOM issues start appearing roughly halfway through the test suite (on a 16GB machine). Workaround is to stop test run at that point, then restart the remaining tests.

@MDoerner

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2017

As mentioned in chat yesterday, make sure your test settings are set to run the tests with a 64 bit procesor architecture. Currently, running all tests consumes a bit more than 3 GB of memory; with a 32 bit process, you only get about 1,3 GB.

The issue seems to be that the VS test runner does not release test objects until all tests have finished.

@Vogel612

This comment has been minimized.

Copy link
Member

commented Oct 4, 2017

Some heap analysis I performed on a testrun suggests that the cause of huge memory consumption when running the tests is Listeners attached to VBEditor.SafeComWrappers.VBA.VBComponents.ComponentAdded that keep massive instances of RubberduckParserState alive.

The relevant event listeners were made static with 36835fb, and later modified with a3cd649 and 812d8bd.

A potential fix is to drop the events into the VBComponents instance instead of keeping them static. That should allow the testrunner to more aggressively GC unused ParserState instances and keep memory usage down:

Heap overview


Detailed analysis of objects attached to largest EventHandler

@Hosch250

This comment has been minimized.

Copy link
Member

commented Oct 4, 2017

The quick-and-dirty fix would be to just not allow creating mocks/parser states in loops in the tests.

@MDoerner

This comment has been minimized.

Copy link
Contributor

commented Oct 31, 2017

Does anyone still have OOM errors with the current built?

@Vogel612

This comment has been minimized.

Copy link
Member

commented Nov 25, 2017

Considered fixed for the purposes of unit-tests. It might be useful to verify the scoping of parser-states has been applied across the board there for later reference

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.