MS ACCESS and VBE hung with heavy CPU\MEM use after parse

[A9G-Data-Droid]

Rubberduck version information Rubberduck version 2.5.0.5394 loading: Operating System: Microsoft Windows NT 10.0.18363.0 x64 Host Product: Microsoft Office x64 Host Version: 16.0.11929.20648 Host Executable: MSACCESS.EXE;

Description After parsing completes without error the VBE and Access host are unresponsive yet not marked as such by the OS. Looking at Task Manager I can see heavy CPU usage and memory slowly climbing. Might be related to Issue #3852

To Reproduce I'm not entirely sure what the test for this would be due to the size of my project.

1. Open my database
2. Open VBE
3. RD parse
4. Everything is dead

Expected behavior I used to be able to hit parse and then open Code Issues to review my code. I can no longer do this.

Screenshots

Logfile This is the only error I see in the log now:

2020-03-24 07:47:40.7308;DEBUG-2.5.0.5394;Rubberduck.Parsing.VBA.Parsing.TokenStreamParserBase;Rubberduck.Parsing.VBA.Parsing.ParsingExceptions.MainParseSyntaxErrorException: extraneous input '\r\n' expecting {'=', WS, LINE_CONTINUATION}
   at Rubberduck.Parsing.VBA.Parsing.ParsingExceptions.MainParseExceptionErrorListener.SyntaxError(IRecognizer recognizer, IToken offendingSymbol, Int32 line, Int32 charPositionInLine, String msg, RecognitionException e) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\Parsing\ParsingExceptions\MainParseExceptionErrorListener.cs:line 14
   at Antlr4.Runtime.ProxyErrorListener`1.SyntaxError(IRecognizer recognizer, Symbol offendingSymbol, Int32 line, Int32 charPositionInLine, String msg, RecognitionException e)
   at Antlr4.Runtime.Parser.NotifyErrorListeners(IToken offendingToken, String msg, RecognitionException e)
   at Antlr4.Runtime.DefaultErrorStrategy.SingleTokenDeletion(Parser recognizer)
   at Antlr4.Runtime.DefaultErrorStrategy.Sync(Parser recognizer)
   at Rubberduck.Parsing.Grammar.VBAParser.lsetStmt() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 9973
   at Rubberduck.Parsing.Grammar.VBAParser.mainBlockStmt() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 2819
   at Rubberduck.Parsing.Grammar.VBAParser.blockStmt() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 2535
   at Rubberduck.Parsing.Grammar.VBAParser.block() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 2377
   at Rubberduck.Parsing.Grammar.VBAParser.ifStmt() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 8881
   at Rubberduck.Parsing.Grammar.VBAParser.mainBlockStmt() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 2784
   at Rubberduck.Parsing.Grammar.VBAParser.blockStmt() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 2535
   at Rubberduck.Parsing.Grammar.VBAParser.block() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 2377
   at Rubberduck.Parsing.Grammar.VBAParser.subStmt() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 12709
   at Rubberduck.Parsing.Grammar.VBAParser.moduleBodyElement() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 2312
   at Rubberduck.Parsing.Grammar.VBAParser.moduleBody() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 2216
   at Rubberduck.Parsing.Grammar.VBAParser.module() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 448
   at Rubberduck.Parsing.Grammar.VBAParser.startRule() in C:\projects\rubberduck\Rubberduck.Parsing\obj\Release\net46\VBAParser.cs:line 336
   at Rubberduck.Parsing.VBA.Parsing.TokenStreamParserBase.ParseSll(String moduleName, ITokenStream tokenStream, CodeKind codeKind) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\Parsing\TokenStreamParserBase.cs:line 86
   at Rubberduck.Parsing.VBA.Parsing.TokenStreamParserBase.ParseWithFallBack(String moduleName, CommonTokenStream tokenStream, CodeKind codeKind) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\Parsing\TokenStreamParserBase.cs:line 47
Token: 
 at L73C32
Kind of parsed code: CodePaneCode

The line causing this parse error is:

LSet DM = DevModeString

(Where DM and DevModeString are both user defined types used to collect printer settings)

Additional context I have a large project that I have been using RD to review my code. I recently added some open source code to this project and RD began to crash the whole Access application. What's odd is that I can break the code down in to parts and the problem goes away. My base program, and two additional open source modules can all be parsed and analyzed individually. It's only when they are all together in the same project that this runaway process is seen. Perhaps it's due to size.

I've been trying to run down this issue looking at logs and I'm beginning to think that there are no related error messages logged for this problem.

[A9G-Data-Droid]

Using the latest version on my project is working fine today. Is it expected that any recent changes would have fixed the issue?

Version 2.5.0.5410
OS: Microsoft Windows NT 10.0.18363.0, x64
Host Product: Microsoft Office x64
Host Version: 16.0.11929.20648
Host Executable: MSACCESS.EXE

[A9G-Data-Droid]

UPDATE: This is still happening but only on a single PC. Looks like the problem is more complicated than I first thought and it might not be something you can solve. The PC is not out of memory. My total memory usage is at 62% and the host application is using ~520MB of RAM in a 64-bit host.

I'm not sure what difference between my PCs would cause this. They have a similar software\OS config because they are both domain managed PCs.

You can close this issue if you believe the problem is on my end.

[ubidev]

Hi Please don't close this issue because I'having the same exact problem since this issue has been opened.

Replacing RD with latest release does not solve the problem I'm using a specialized/isolated vm for Access/SQLServer development for a customer.

Version 2.5.0.5410
OS: Microsoft Windows NT 10.0.18363.752 x64
Host Product: Microsoft Office 2013 x32 Pro Plus
Host Version: 15.0.5111.1001
Host Executable: MSACCESS.EXE

Thanks in advance ubidev

[A9G-Data-Droid]

Thanks @ubidev, I wasn't sure if it was just me. Anything you can add would be helpful. I'm not sure what to look at next. I tried capturing the behavior using ProcMon by SysInternals. I found that Access isn't actually doing anything while the code inspection window is taking up all the CPU.

[A9G-Data-Droid]

I see this for when I try to close Access after it is hung by a parse:

The program MSACCESS.EXE version 16.0.11929.20648 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Security and Maintenance control panel.
 Process ID: 2638
 Start Time: 01d6084cccabfa43
 Termination Time: 4294967295
 Application Path: C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE
 Report Id: cb72665f-0a92-4fc0-93a2-c5a49cd428ab
 Faulting package full name: 
 Faulting package-relative application ID: 
 Hang type: Top level window is idle

[ubidev]

After many tests assisted with different vm snapshots and their associated manually maintained change logs, I've discovered that the issue is introduced in build Rubberduck.Setup.2.4.1.5227-pre

Build Rubberduck.Setup.2.4.1.5226-pre and previous ones do not exhibit the aforementioned issue.

Here are the RD trace logs of those 2 builds. They were generated on a previous november snapshot of my dev vm running earlier OS/Office builds, confirming that the issue was not introduced via an OS/Office update since then

Hope this helps finding the root cause. Cheers ubidev BAD Rubberduck.Setup.2.4.1.5227-pre - RubberduckLog.txt OK Rubberduck.Setup.2.4.1.5226-pre - RubberduckLog.txt

[Vogel612]

The prerelease you identified points to #5306 as the root cause, which seems ... weird, to say the least, but it's a jumping off point for sure.

[A9G-Data-Droid]

One of the symptoms is that the code inspection window shows the spinning ducks and never loads the results of the completed parse. There could be some odd combination of things related to the display of results that is causing the endless loop. It only happens on very large projects for me so this could be related to the number of items in the code inspection window. You could test for this by producing a few thousand inspection results and see if you get the same behavior.

NOTE: It started when I imported a new module that uses Hungarian notation. This added over 500 inspection results to a project that already had a long list of variables that should be renamed.

[ubidev]

The prerelease you identified points to #5306 as the root cause, which seems ... weird, to say the least, but it's a jumping off point for sure.

Encouraging lead! Since this is a relatively small commit, reversing the changes to validate its implication in the problem seems promising!

I'd do it myself but unfortunately, I don't have the knowledge required.

Thanks in advance for all your help and plz be safe in these rough times :-)

[MDoerner]

I think we have some infinite loop in the UI in the grouping grid between its scrollbars and the groups going on. I will try to debug this somehow in the next weeks.

One question though: does this happen while all groups are still collapsed or are groups already expanded?

[ubidev]

One question though: does this happen while all groups are still collapsed or are groups already expanded?

It happens everytime I do the following. (no panes are visible except for code)

• open an access project
• ALT-F11 to open VBE
• Click the "Pending" button
• When at the "Ready" state, the program goes in "not responding" mode as soon as I click something. task manager confirms activity and growing memory usage.
• I kill the process

Don't hesitate to ask if I can assist you.

Have a great wathever u doin! ubidev

[Skoddiethecat]

I'm having the same issue on my machine when loading projects that have 500+ inspections flagging. I tried disabling Run inspections automatically on successful parse but did not observe any difference. I've downgraded to 2.4.1.4627 in the interim which loads the same projects without issue using the same settings.

The issue does not occur in 2.5.0.5410 unless the large projects are loaded.

Version 2.5.0.5410
OS: Microsoft Windows NT 10.0.18362.0, x64
Host Product: Microsoft Office x86
Host Version: 16.0.12624.20382
Host Executable: EXCEL.EXE

Let me know if there's anything I can do to help out, otherwise I will stay on the old version for the moment 😊

[joyfullservice]

I am having the same issue on my system as well. Microsoft Access 2010, no other COM add-ins loaded.

[joyfullservice]

FYI, still experiencing this issue on 2.5.0.5443-pre. Unfortunately it renders this add-in unusable for me for development in Microsoft Access. To reproduce the issue, download the database file from https://github.com/joyfullservice/msaccess-vcs-integration/releases/latest, and try to parse the code in the IDE. I realize that this is a more complex project, but many of the projects that I develop on a daily basis are this complicated or even more so.

Hopefully a sample file to reproduce the issue will help on the debugging side. Thanks for your contributions to the VBA programming community! A tool like this helps us all become better programmers as we learn from the suggestions and related articles.

[A9G-Data-Droid]

@joyfullservice It's a super flaky issue too. It has come and gone for me. I am currently able to parse the latest version v3.1.23 of the Version Control addin using the latest version 2.5.0.5443-pre of RubberDuck. It might depend on which PC I am using.

[MDoerner]

@joyfullservice Thank you very much for the link to your repo. I am finally able to reproduce the issue. So, I am finally be able try to figure out what is really going on.

[MDoerner]

The PR above resolved the issue for me using the linked Access database. However, I am not fully sure this fixes the problem completely since I did not experience the issue with other projects. So I would be grateful if others experiencing this issue could test whether the latest pre-release actually fixes it.

[ubidev]

Hopefully I will be able to test this ASAP before Monday. Thanks a lot and have an amazing COVID free week end :-)

ubidev

---

De : Max Dörner notifications@github.com Envoyé : Friday, May 29, 2020 3:35:28 PM À : rubberduck-vba/Rubberduck Rubberduck@noreply.github.com Cc : Georges VIVIER gvivier@ubilogia.com; Mention mention@noreply.github.com Objet : Re: [rubberduck-vba/Rubberduck] MS ACCESS and VBE hung with heavy CPU\MEM use after parse (#5442)

The PR above resolved the issue for me using the linked Access database. However, I am not fully sure this fixes the problem completely since I did not experience the issue with other projects. So I would be grateful if others experiencing this issue could test whether the latest pre-release actually fixes it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/rubberduck-vba/Rubberduck/issues/5442#issuecomment-636149943, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMPK2MELQAPB7GDBHFVWX3RUAFABANCNFSM4LSXJCEA.

[ubidev]

After a quick validation using release Rubberduck v2.5.0.5457-pre, I can confirm that on my side, the frozen state has dissapeared and the plugin seems to work as it does not freeze at the end of all inspections. I'll will work more with the tool during the coming week!

Good Job! Thanks :)

[joyfullservice]

5506 fixed it for me! I was able to load the project and run a full parse for the first time without the application hang I was experiencing before. Thank you @MDoerner for your work on this!

[MDoerner]

Since the latest PR seems to have helped, I close this issue. However, should the problem persist for somebody, please reopen it.