Apparent memory leak in DockingManager

Offen Anfängerfreundlich
#1,812 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
72/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
csharp
Bereich
desktop

Rechercherichtung

Beginne damit, CollectLayoutItemsDeleted, RemoveDocumentLayoutItem und LayoutItem.Detach() im DockingManager-Code zu lesen. Reproduziere die gemeldete Schleife, die LayoutAnchorable-Elemente hinzufügt und schließt, und prüfe dann, ob geschlossene Elemente aus _layoutItems und _logicalChildren entfernt und eingesammelt werden können. Erledigt ist die Aufgabe, wenn das Leck behoben ist, ohne die Bereinigung von Dokumenten zu beeinträchtigen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

An application is set up with a DockingManager in xaml like

<UserControl
    x:Class="Test.MainDockingContentContainer"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:xcad="clr-namespace:Xceed.Wpf.AvalonDock;assembly=Xceed.Wpf.AvalonDock"
    xmlns:layout="clr-namespace:Xceed.Wpf.AvalonDock.Layout;assembly=Xceed.Wpf.AvalonDock">
  <Grid>
    <xcad:DockingManager x:Name="DockManager">
      <layout:LayoutRoot>
        <layout:LayoutPanel Orientation="Horizontal">
          <layout:LayoutAnchorablePaneGroup Orientation="Vertical">
            <layout:LayoutAnchorablePane x:Name="A" DockHeight="0.7*"/>
            <layout:LayoutAnchorablePane x:Name="B" DockHeight="0.3*" />
          </layout:LayoutAnchorablePaneGroup>
        </layout:LayoutPanel>
      </layout:LayoutRoot>
    </xcad:DockingManager>
  </Grid>
</UserControl>

and code-behind which is equivalent to

partial MainDockingContentContainer()
{
  InitializeComponent()
  A.Name = "A";
  B.Name = "B";
}

this gets used to add/remove content in code, essentially like this:

var testPane = mainDock.DockManager.Layout.Descendents().OfType<LayoutAnchorablePane>().Where( l => l.Name == "A" ).FirstOrDefault();
for( var i = 0 ; i < 20 ; i++ )
{
  var testWin = new LayoutAnchorable { Content = new System.Windows.Controls.TextBlock { Text = "content" } };
  testPane.Children.Add( testWin );
  testWin.Show();
  testWin.Close();
}

The result of this is that after this loop ran testPane.Children is empty as expected, but

  • DockingManager._layoutItems still contains 20 LayoutAnchorableItem
  • that LayoutAnchorableItem's LayoutElement still is set to testWin (though its Root is null), and its Model still set to the TextBlock
  • both can never get garbage collected so in an actual application causes severe leaks, plus _layoutItems grows bigger and bigger
  • similar issue exists for DockingManager._logicalChildren

In other words: even though the LayoutAnchorable was closed indicating the caller doesn't need it anymore, it remains in memory forever. I first thought perhaps what I'm doing is not intended usage (but if not Close, what else would have to be used?) but on further inspection I think it's an oversight: core issue seems to be that the LayoutItem.Detach() method (which is responsible for clearing LayoutElement and Model) never gets called. I also see no code in DockingManager which does that, whereas that should probably be the place where it should happen; also because there is already CollectLayoutItemsDeleted and and which does

      LayoutItem[] array = _layoutItems.Where( ( LayoutItem item ) => item.LayoutElement.Root != Layout ).ToArray();
      for( int i = 0 ; i < array.Count() ; i++ )
      {
        LayoutItem layoutItem = array[ i ];
        RemoveDocumentLayoutItem( layoutItem.LayoutElement as LayoutDocument );
      }

and RemoveDocumentLayoutItem is

    LayoutItem layoutItem = _layoutItems.FirstOrDefault( ( LayoutItem item ) => item.LayoutElement == contentToRemove );
    if( layoutItem != null )
    {
      layoutItem._ClearDefaultBindings();
      layoutItem.Detach();
      _layoutItems.Remove( layoutItem );
      if( contentToRemove != null && contentToRemove.Content != null && contentToRemove.Content is UIElement )
      {
        InternalRemoveLogicalChild( contentToRemove.Content );
      }
    }

So I guess what is missing here is there is actually nothing specific to LayoutDocument in RemoveDocumentLayoutItem, it just looks up LayoutItem, and simply removing as LayoutDocument fixes the issue?

Vorherrschende Sprache
C#
Sterne
4.2k
Forks
907
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus xceedsoftware/wpftoolkit

Alle Issues in xceedsoftware/wpftoolkit

Ähnliche Issues

Weitere Issues zu C#

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.