April 15, 2019 at 19:18 #24675
I finally captured a log entry after a restart. Let me know if it makes any sense.C++12345678910111213141516171819202122232425262728293031323334353637383940414243<entry><record>1530</record><time>2019/04/15 17:58:55.524</time><type>Information</type><source>MruList</source><description>Entering AddItem. Persistence data for item: C:\Users\phil\source\repos\FreeRTOS_MCU_MIDI\FreeRTOS_MCU_MIDI\STemWin\App\win_SeqControls.c</description></entry><entry><record>1531</record><time>2019/04/15 17:58:55.524</time><type>Information</type><source>MruList</source><description>Entering TryPromoteItem</description></entry><entry><record>1532</record><time>2019/04/15 17:58:55.524</time><type>Information</type><source>MruList</source><description>Entering PromoteItemAt and found the index of the item to be 0</description></entry><entry><record>1533</record><time>2019/04/15 17:58:56.765</time><type>Information</type><source>Manage Visual Studio Performance</source><description>End execution cost summary for IdeModeChange scenario and ToolWindow component</description></entry><entry><record>1534</record><time>2019/04/15 17:58:56.765</time><type>Information</type><source>Manage Visual Studio Performance</source><description>End execution cost summary for IdeModeChange scenario and ToolWindow component</description></entry><entry><record>1535</record><time>2019/04/15 18:12:29.749</time><type>Error</type><source>Editor or Editor Extension</source><description>System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown. at Microsoft.VisualStudio.Editor.Implementation.MarkerManager.GetPrioritizedMarkerSpans(IList<code>1 unsortedMarkers) at Microsoft.VisualStudio.Editor.Implementation.MarkerManager.d__68.MoveNext() at Microsoft.VisualStudio.Editor.Implementation.TextMarkerViewTagger.d__9.MoveNext() at Microsoft.VisualStudio.Text.Tagging.Implementation.TagAggregator</code>1.<GetTagsForBuffer>d__39.MoveNext() --- End of stack trace from previous location where exception was thrown --- at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)</description></entry></activity>
April 15, 2019 at 19:25 #24676
- This topic was modified 1 year, 2 months ago by jona.
It looks like Visual Studio runs out of memory somewhere inside the logic responsible for handling the editor markers. If we encounter this behavior during our internal tests, we should be able to fix it. Please also consider filing a bug report with Microsoft, as it looks like the problem might be on their side (the exception stack does not contain any VisualGDB-related frames).April 15, 2019 at 19:42 #24678
I don’t know if there is anything different when working in C#/WPF but it only occurs when using VGDB. I’ve been living with it. I thought I would send this log just in case.April 15, 2019 at 20:05 #24679
Most likely something about a specific file is triggering a memory leak somewhere inside Visual Studio. As the error occurs outside the VisualGDB codebase, it is hard for us to pinpoint the root cause of this.
The best advice we could give is to try splitting the source file that typically triggers this into multiple smaller files. This will reduce the amount of information Visual Studio has to process and might prevent the problem from happening.April 16, 2019 at 01:15 #24682
This occurs with any file. Never happens when coding C#. I’ll try to look for more clues as I work. Thanks for your response!May 7, 2019 at 20:48 #24920
Updated and reinstalled VS2017. Still restarts every half hour or so.
Installed VS2019. Same thing. It is VGDB. No doubt.
I write C# with this same system and I never see that problem.
Sometimes I lose work. Sometimes it recovers files. Either way, makes daily work very difficult.May 8, 2019 at 05:38 #24935
Sorry, we still need a specific sequence of steps that could reproduce the problem on our side in order to do anything about it. Generally, C# and C++ use completely different underlying mechanisms in Visual Studio, so it could be triggered by something completely different.
The only other similar issue known to us is that running debug sessions with large amounts of live variables would leak memory due to a bug in VS (about 200 live variables with maximum refresh rate consume all available RAM in about 2-3 hours).May 8, 2019 at 15:37 #24942
Launch Visual Studio.
Begin working.May 12, 2019 at 16:13 #24967
While working on GDB projects I can watch the memory leak in Task manager. It doesn’t budge in other projects. I am anxious to solve this. Do you have any suggestions as to where I might look to track this down?May 12, 2019 at 17:31 #24969
Please try attaching another instance of Visual Studio to the one causing memory leaks (ensure you have the ‘auto’ selection for debugging engines). Then select Debug->Windows->Show Diagnostic Tools and switch to Memory View. Start your work session and do the regular work tasks for about 5 minutes. Then click the “Take snapshot” button in the Memory view of the Diagnostic tools and work for another 10 minutes. Then click “Take snapshot again” and wait for the updated line to appear.
Finally click on the difference between the memory snapshots (see the attached file) and share a screenshot of the snapshot window that will open up. It will list the exact memory differences between the 2 snapshots, showing what has consumed the memory.
Attachments:You must be logged in to view attached files.May 12, 2019 at 17:59 #24971
Thanks.. I will give that a shot this week and report the results.
You must be logged in to reply to this topic.