Kolejka Finalizer rosnąca, ale zarządzane stosy nie

Question

Mamy jakiś wyciek, którego natury nie rozumiem. Sterty Gen0/1/2 nie powiększają się, jednak zestaw roboczy rośnie aż do OOM.

DebugDiag informuje mnie, że CLR.DLL jest właścicielem rosnącej pamięci, a także mówi mi, że mamy rosnącą kolejkę finalizatora - setki tysięcy obiektów Texture2D (jej aplikacja XNA), które rosną wraz z upływem czasu .. Jednak nie ma profilera (dotTrace , Ants, CLR Profiler) mogą znaleźć te obiekty - nie wyświetlają się w stercie, a CLRProfiler twierdzi, że nigdy nie są przydzielane.

Tak więc wyglądam w WinDbg - po raz kolejny widzę rosnącą kolejkę Finalizera pełną Texture2D. fReachable jest puste i twierdzi, że wszystkie te obiekty i tak znajdują się na stercie.

*0:038> !finalizequeue 
SyncBlocks to be cleaned up: 0 
MTA Interfaces to be released: 0 
STA Interfaces to be released: 0 
---------------------------------- 
generation 0 has 1881 finalizable objects (33e365b0->33e38314) 
generation 1 has 41580 finalizable objects (33e0dc00->33e365b0) 
generation 2 has 685816 finalizable objects (33b70020->33e0dc00) 
Ready for finalization 0 objects (33e38314->33e38314) 
     MT Count TotalSize Class Name 
......snip...... 
00ce67e0 726827  49424236 Microsoft.Xna.Framework.Graphics.Texture2D* 

Następnie szukam tych 726 000 egzemplarzy, aby móc stwierdzić, kto jest ich właścicielem. Problem polega na tym, że dumpheap mówi, że jest tylko 218. To prawie wszystko, czego się spodziewam i co mówią mi zarządzani profilerzy.

*0:038> !dumpheap -stat -type Microsoft.Xna.Framework.Graphics.Texture2D 
total 0 objects 
Statistics: 
     MT Count TotalSize Class Name 
00ce67e0  218  14824 Microsoft.Xna.Framework.Graphics.Texture2D 
Total 218 objects* 

Skąd pochodzą pozostałe elementy z kolejki finalizatora? W tej chwili podejrzewam, że rosnąca kolejka finalizatora dla alokacji pamięci rośnie wraz z rozwojem, a tym samym OOM. To tak, jakby te 218 elementów zostały dodane do kolejki Finalizer wiele razy z jakiegoś powodu.

Dziękujemy

Andy

Answer 1

Dla kompletności o to, co się dzieje.

Istnieje problem z XNA, który powoduje wywołanie ReRegisterForFinalize na Texture2Ds, jeśli uzyskasz dostęp do kolekcji Device.Texture []. Sunburn ma dostęp do tej kolekcji w każdej ramce, aby obejść inny problem z XNA, więc jeśli masz dużo tekstur, to może się to bardzo szybko narastać.

Istnieje kilka miejsc w XNA (Texture3D itp.), Które używają tego samego wzorca, więc zakładam, że możesz to zmienić na wiele sposobów.

Ponieważ nie ma oznak XNA 5 musieliśmy obejść to - odkryłem, że po prostu wywołanie SuppressFInalize po uzyskaniu dostępu do kolekcji usuwa dodatkowy element, który został dodany. Uważamy, że jest bezpieczna :-) Chłopaki z Sunburn dodają poprawkę do swojego kodu i mamy nadzieję, że problem zniknie.

Answer 2

Może to być ta sama instancja jest ponownie dodany do kolejki sfinalizować? Od dokumentów na Object.Finalize:

Finalizacja jest automatycznie wywoływana tylko raz na danej instancji, chyba że obiekt jest ponownie rejestrowany przy użyciu mechanizmu takiego jak GC.ReRegisterForFinalize i GC.SuppressFinalize nie został później wywołany.

To jedyne wyjaśnienie, które wydaje się pasować do tego, co tu widzisz. Nie wiem, dlaczego byłby ponownie zarejestrowany do finalizacji.