Apparent memory leak in DockingManager
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 2/5
- Temps estimé
- 1-3 heures
- Accessibilité débutants
- 72/100
Piste de recherche
Commencez par lire CollectLayoutItemsDeleted, RemoveDocumentLayoutItem et LayoutItem.Detach() dans le code de DockingManager. Reproduisez la boucle signalée qui ajoute et ferme des éléments LayoutAnchorable, puis vérifiez si les éléments fermés sont supprimés de _layoutItems et _logicalChildren et peuvent être récupérés. La tâche est terminée lorsque la fuite est corrigée sans perturber le nettoyage des documents.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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?
- Langage dominant
- C#
- Étoiles
- 4.2k
- Forks
- 907
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de xceedsoftware/wpftoolkit
-
Difficulté 3/5 1-2 jours Accessibilité débutants 62/100
xceedsoftware/wpftoolkit#1811 · 5 commentaires ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
xceedsoftware/wpftoolkit#1808 · 1 commentaire ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 48/100
xceedsoftware/wpftoolkit#1807 · 2 commentaires ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 35/100
xceedsoftware/wpftoolkit#1806 · 2 commentaires ·
-
Plus Edition. Incorrect window position restoration after returning from the maximized state.Ouverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 45/100
xceedsoftware/wpftoolkit#1804 · 1 commentaire ·
Toutes les issues de xceedsoftware/wpftoolkit
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
-
area:repo elsa 3 prio low triaged type:bug
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
elsa-workflows/elsa-core#9258 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 90/100
iokode/OpinionatedFramework#140 ·
-
accessibility effort: small enhancement
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
pedersebastian/CustomBossChallenge#185 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100