System.OutOfMemoryException' was thrown. while i am importing vba classes from local folders #3730
Labels
bug
Identifies work items for known bugs
Comments
|
@manjugb we really need a few things to find where the problem is in the first place:
Last but not least: Does this happen every time when importing any class or can you possibly nail it down to a specific class (and if so, can you make that class smaller and still reproduce the problem?) |
|
here i attached the log |
|
its happen every time when import |
|
check in the txt file line number |
|
System Information: As suspected, the host is a 32-bit host, which means that Rubberduck apparently outdoes the 2GB mark when preprocessing ... At this point I should mention that the stacktrace is on line 21k in the log. It seems there's a humungous amount of modules that we parse, which of course takes a toll on memory... @manjugb The system requirements (especially those for memory) should generally be fulfilled by having a 64-bit OS and host, as well as ~8GB of RAM. Any more than that would most likely brick the VBE anyways. |
|
this is least size project which containes arround 20 classes from dev, i started write my rubberduck tests [5 tests classes which containes over all 25 test methods] , i must import basic needs of modules, then only my tests works. |
|
@MDoerner raised an interesting point in chat just now: If you import these modules in rapid succession, Rubberduck may still be working on the first import, while you already import the next module. This can lead to a significant increase in memory consumption ... Could you try waiting for Rubberduck to report a Ready status before importing the next module? |
|
@manjugb haven't looked at the full log, but are you importing the modules from the Code Explorer or from the VBE's own "import" command? The VBE doesn't allow selecting multiple files AFAIK, but Rubberduck's import tool does - and when RD imports the files it knows to only initiate a parse after all modules are imported... whereas importing files one at a time via the VBE's import command makes Rubberduck work harder - a module is created in the VBE, we launch a parse task; then another module is created, we try to cancel the first task and launch a new one - then another module is created in the VBE, we try to cancel the previous one, and launch a parse task - this one completes, and inspections start running - then another module is created in the VBE, so we cancel the previous parse task, but inspections keep running in the background (we need to fix that); we launch a new parse task, and so on. When RD is doing the import, we disable "module created" event handling, import all the selected files, re-enable event handling, and launch one parse task that picks up all the new modules. FWIW I'm running 32-bit Office 2010 too (albeit with 8GB RAM), and my 107-module project imports & exports just fine :0) |
|
OBTW: linking to #3347 for another instance of RAM consumption being heavy... |
|
Great thanks for explanation, i will try do as you explained on monday |
|
@manjugb looking at the logs right now - your project seems to have lots of references: If some of these libraries aren't needed, I'd recommend removing their reference - that could greatly improve the memory situation. With all these libraries loaded it wouldn't surprise me that Rubberduck's resolver would be caching something in the ballpark of a million Note that Lines 182 and 183 of The logs contain a number of resolver failure notifications involving relatively complex expressions; consider splitting member accesses across multiple instructions - if a member returns a |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
steps to reproduce:
usually when developer finishes or modifiedsclasses , usually i import into my rubberduck tests , to make my tests should work or not. when ever i tried to import , i am getting parse error saying system.outofmemory
here is log
The text was updated successfully, but these errors were encountered: