Apparent memory leak in DockingManager
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 72/100
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._layoutItemsstill contains 20LayoutAnchorableItem- that LayoutAnchorableItem's
LayoutElementstill is set totestWin(though itsRootis null), and itsModelstill set to theTextBlock - both can never get garbage collected so in an actual application causes severe leaks, plus
_layoutItemsgrows 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
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus xceedsoftware/wpftoolkit
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 62/100
xceedsoftware/wpftoolkit#1811 · 5 Kommentare ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
xceedsoftware/wpftoolkit#1808 · 1 Kommentar ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 48/100
xceedsoftware/wpftoolkit#1807 · 2 Kommentare ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 35/100
xceedsoftware/wpftoolkit#1806 · 2 Kommentare ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 45/100
xceedsoftware/wpftoolkit#1804 · 1 Kommentar ·
Alle Issues in xceedsoftware/wpftoolkit
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
-
area:repo elsa 3 prio low triaged type:bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
elsa-workflows/elsa-core#9258 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
iokode/OpinionatedFramework#140 ·
-
accessibility effort: small enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
pedersebastian/CustomBossChallenge#185 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100