search

rubberduck-vba / Rubberduck

Every programmer needs a rubberduck. COM add-in for the VBA & VB6 IDE (VBE).
https://rubberduckvba.com
GNU General Public License v3.0
1.92k stars 301 forks source link

Access violation reading location 0x00000073 for Excel.exe 32-bit #1614

Closed PeterMTaylor closed 7 years ago

PeterMTaylor commented 8 years ago

Using the latest sync and VS2015 with symbols loaded in the debugger. Executing Excel.exe 32 bit on my 64 bit machine. All I was doing was waiting til Book1 sheet is ready. Goto Developer->VisualBasic button. Output is showing... Rubberduck.UI.Command.MenuItems.RubberduckCommandBar : 2016-05-28 16:19:04.0147;DEBUG;Rubberduck.UI.Command.MenuItems.RubberduckCommandBar;RubberduckCommandBar status text changes to 'Loading references'.; Rubberduck.UI.Command.MenuItems.RubberduckCommandBar : 2016-05-28 16:19:04.1241;DEBUG;Rubberduck.UI.Command.MenuItems.RubberduckCommandBar;RubberduckCommandBar status text changes to 'Loading references'.; Exception thrown at 0x7511256A (kernel32.dll) in EXCEL.EXE: 0xC0000005: Access violation reading location 0x00000073. capture call trace on linq enumberable tsource capture linq enumerable tsource capture source linq enumerable tolist

PeterMTaylor commented 8 years ago

Using @comintern's clone latest commit named af901c2 without IsBadReadPtr calls. I am happy to say it works without any violations after 30 mins of using Excel, just to let you know and can be safely merged if you wish @retailcoder.

PeterMTaylor commented 8 years ago

Sync my local with https://github.com/rubberduck-vba/Rubberduck/commit/83b08c4500fd13f945b6589934ae2fa2381f9ff8 and found IsBadReadPtr returned with @ThunderFrame changes and this error has reoccurred.

comintern commented 8 years ago

99% sure that something is getting unpinned in memory again (see the comment on #1624). When I was going over the memory dumps, it looked almost like oleaut32.dll is doing something funky with its heap - maybe compacting it or reloading the tlb at some point? It's not exactly clear why the changes in https://github.com/rubberduck-vba/Rubberduck/commit/83b08c4500fd13f945b6589934ae2fa2381f9ff8 would have touched this again unless it changed the behavior of the GC in some unpredictable way.

retailcoder commented 8 years ago

@comintern is it the yield state machine interacting with GC and ultimately causing this?

comintern commented 8 years ago

@retailcoder - That's the best theory that I can come up with at this point. It should be leaking memory, not eating it.

comintern commented 8 years ago

@PeterMTaylor - Can you test the current codebase at some point that's convenient for you? I pulled out the yield state machine.

PeterMTaylor commented 8 years ago

Sure @comintern.

However I am unable to interpret the results as if a false positive or not.

On a clone of commit https://github.com/rubberduck-vba/Rubberduck/commit/8721c6c8afe1d4cd39c27f7c3326dbc1b8ebb408. No crashes or issues of this type reported.

When I use my own fork of rubberduck-vba/next synced with https://github.com/rubberduck-vba/Rubberduck/commit/8721c6c8afe1d4cd39c27f7c3326dbc1b8ebb408. It crashes with same error just over 1 min of execution time. I may have stuffed up my sync process.

Here are the snaps for the sync with my fork. capture 1649 error call disassembly capture 1649 error call stack capture 1649 error source

PeterMTaylor commented 8 years ago

Ok I have re-checked that I still can make the error https://github.com/PeterMTaylor/Rubberduck.git

Please use my commit at https://github.com/PeterMTaylor/Rubberduck/commit/cbb4c98c0d85e11efb437923e46770aba0335bb0 to see if this helps. @Hosch250, @comintern, @retailcoder to see if the error reoccurs again.

Need to mentioned I also have PowerPivot for 2010 and PowerQuery loaded with my Excel.exe 2010 which are loaded but not used.

retailcoder commented 7 years ago

deemed fixed