Open CharlesRHall opened 5 years ago
Did it happen to create a log file?
The logs would confirm what specific "new version" you're using; you can find the logs under %appdata%\rubberduck\logs
. They're disabled by default, but enabled on first startup specifically to log this kind of problem.
A parser error typically means your code doesn't compile. Does your VBA project compile? If you click the "parse error" button in the toolbar, a "parser errors" toolwindow should pop up with the actual parser error details - and these are in the logs too.
If your code does compile, then we would be very interested in getting to the bottom of this, since as far as we know at this point our parser handles every bit of legal VBA code we could possibly throw at it.
The crash on opening the settings window was a problem in an earlier build. Are you running 2.3.1?
Note that without further information about the version you're running and the parser error (i.e. the logs), there's nothing we can do other than shrug and say "it doesn't do that here".
I disabled, /unloaded all my addins and com addins and the settings started to work the log had been disabled, so I enabled it my code compiles but I still get an error see previous attachment
@CharlesRHall is QS_TAI_SuplrRptApp.ReportTblCls
your own code or some external library code?
my own code
Ok, let's see if we can make a MCVE here. Can you create a new blank excel spreadsheet, and put only that procedure (and only what it actually needs -- mabye just the module?) and then try to parse that stripped down codebase?
does it parse all workbooks or just the active one - do I have to close the original before parsing?
ATM, it will parse all unlocked VBA projects. To ensure no funny side effects, best to close all other workbooks and have only one workbook that contains the minimum code, ensure it is fully compiled then try to parse only that.
Rubberduck parses all (unlocked) projects loaded in the VBE, so yeah you'd have to close the original. Since this is an "out of memory" exception I'd actually recommend closing the process and launching a fresh one.
I'm rather curious about what other add-ins you're running - more specifically which one is interfering with our settings dialog...
The good news is that it's not quite a parser error, rather an exception that was thrown while acquiring the declarations in a specific module (which means that code was correctly parsed, so there's that!):
2018-12-13 14:18:08.6119;WARN-2.3.1.4308;Rubberduck.Common.LogLevelHelper; Rubberduck version 2.3.1.4308 loading: Operating System: Microsoft Windows NT 6.1.7601 Service Pack 1 x64 Host Product: Microsoft Office 2010 x86 Host Version: 14.0.7225.5000 Host Executable: EXCEL.EXE; 2018-12-13 14:18:23.8847;ERROR-2.3.1.4308;Rubberduck.Parsing.VBA.DeclarationResolving.DeclarationResolveRunnerBase;Exception thrown acquiring declarations for 'QS_TAI_SuplrRptApp.ReportTblCls' (thread 9).;System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown. at System.Collections.Concurrent.ConcurrentDictionary
2..ctor(Int32 concurrencyLevel, Int32 capacity, Boolean growLockArray, IEqualityComparer
1 comparer) at System.Collections.Concurrent.ConcurrentDictionary2..ctor() at Rubberduck.Parsing.VBA.ModuleState..ctor(ConcurrentDictionary
2 declarations) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\ModuleState.cs:line 34 at Rubberduck.Parsing.VBA.RubberduckParserState.AddDeclaration(Declaration declaration) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\RubberduckParserState.cs:line 756 at Rubberduck.Parsing.VBA.DeclarationResolving.DeclarationResolveRunnerBase.ResolveDeclarations(QualifiedModuleName module, IParseTree tree, IDictionary`2 projects, CancellationToken token) in C:\projects\rubberduck\Rubberduck.Parsing\VBA\DeclarationResolving\DeclarationResolveRunnerBase.cs:line 160
The exception being an OutOfMemoryException
, I'm wondering a few things:
ok - progress
once I unloaded my vbe addins then the parsing error went away
I use MZ-Tools 8.0 - VBA and VBE Tools 2.0
loaded those addins again and it still parses - weird
I thought I had it narrowed down to one addin - PowerPivot Utilities - all other addins loaded everything parsed - added the PowerPivot Utilities and got the parsing error - removed the PowerPivot Addin, and everything parsed again.
However, then did not load my model, and just loaded the PowerPivot Addin - and it parsed fine - then loaded my model, and it still parsed fine
something weird is going on - any suggestions?
What is Excel's memory usage when it has the powerpivot addin loaded? Then when you parse with RD, how much memory is used?
Thanks for taking the time to investigate this. PowerPivot is (can be) a rather memory-intensive add-in.. and so is Rubberduck. I have a very similar environment to yours here:
Version 2.3.1.4318 OS: Microsoft Windows NT 6.1.7601 Service Pack 1, x64 Host Product: Microsoft Office 2010 x86 Host Version: 14.0.7212.5000 Host Executable: EXCEL.EXE
I have the PowerPivot add-in installed too, but I have to say I haven't been using it in macro-enabled Excel workbooks... must be why I'm not experiencing the same kind of memory pressure.
We need to take steps to improve Rubberduck's memory footprint, but this isn't a trivial thing to address, given Rubberduck needs to generate and analyze a truckload of metadata about the code and its referenced type libraries. Ideas include offloading the data to a local database, which would move that memory out of the host process space, among other advantages.
I'm thinking maybe we should add a note under "known issues" in the release notes, something like:
Memory pressure in 32-bit hosts: Rubberduck may not work correctly in a 32-bit host if the process is shared with other memory-intensive add-ins, such as Microsoft Power Pivot.
If you still have the installer media for Office 2010, consider removing Office and re-installing the 64-bit version; that should help with the memory pressure. I don't like making this recommentation (Rubberduck should work fine in a 32-bit host), but I somehow wish this were a parser bug... no matter how hard fixing the grammar can be, they're always easier to fix than an OutOfMemoryException
!
thanks for the insight - but I need to clarify some things - I do use powerpivot but not routinely, so it was not loaded - I used powerquery a lot, and it too is memory intensive so I will be careful. The Addin that was causing the problems was one developed by someone else (not microsoft) and just adds some helpful tools - I don't use it, but I guess I did at one point, so it was still loading. I will disable it and see if the problems come back. I will keep experimenting with RD - it still seems flakey and crashes Excel, but it seems better than 2.0.
As to recommending user move to 64 bit, as an excel consultant, that is not desired - microsoft in their infinite wisdom has not made 64 bit versions of their most useful libraries, so users get less useful tools from me when they move to 64bit. 32bit is more than capable for most of my clients.
So, I need to continue to develop in 32bit to satisfy my client's which means I need to find a way for your tool to work in 32 bit.
Will let you know of any other repeatable problems
Thanks for your fast response
BTW - there is a utility to expand Excel 2010 32bit to use all of the 4GB rather than 2GB - I had forgot to use this utility on the latest version - which I have done now - maybe that will solve the memory constraints
I am just trying out the new version after bailing after having tried version 2.0 - and so far things have been flakey.
When I parse the first time, I get an Unexpected Error status in the toolbar, but no additional information that would help me track it down - the only option is to refresh.
And when I refresh I get the same status - first it says parsing error, then unexpected error
And when I click on Settings, it crashes Excel