Hourly crashes

Sysprogs forums Forums VisualGDB Hourly crashes

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #24675
    jona
    Spectator

    I finally captured a log entry after a restart. Let me know if it makes any sense.

    <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 &apos;System.OutOfMemoryException&apos; was thrown. at Microsoft.VisualStudio.Editor.Implementation.MarkerManager.GetPrioritizedMarkerSpans(IList1 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.TagAggregator1.&lt;GetTagsForBuffer&gt;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>
    • This topic was modified 5 years ago by jona.
    #24676
    support
    Keymaster

    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).

    #24678
    jona
    Spectator

    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.

    #24679
    support
    Keymaster

    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.

    #24682
    jona
    Spectator

    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!

    #24920
    jona
    Spectator

    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.

    #24935
    support
    Keymaster

    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).

    #24942
    jona
    Spectator

    STEPS:

    Launch Visual Studio.

    Begin working.

     

    #24967
    jona
    Spectator

    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?

    #24969
    support
    Keymaster

    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.
    #24971
    jona
    Spectator

    Thanks.. I will give that a shot this week and report the results.

Viewing 11 posts - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.