Das ist ein wirklich verrückter Bug. Im Folgenden wird ein OutOfMemoryException für XML-Snippits angegeben, die sehr kurz und einfach sind (z. B. <ABC def='123'/> ):
Ich habe diesen MSDN-Artikel gelesen, wenn ich XmlSerializer mit zusätzlichen Parametern verwende Im Konstruktor würde ich jedes Mal, wenn es aufgerufen wurde, uncachete Serializer-Assemblys generieren, was zu einem Assembly Leak führte. Aber ich verwende keine zusätzlichen Parameter im Konstruktor. Es passiert auch beim ersten Aufruf in einer frisch gestarteten AppDomain, das macht auch keinen Sinn.
Was gibt's?
Nun, die letzte Antwort auf meine Frage wird nicht jedem helfen, der darauf stößt, aber einige meiner Kollegen haben dieses Monate später auch auf ein anderes System mit einem anderen Produkt gestoßen. Die haben gelacht, als sie Monate später meinen Beitrag hier gefunden haben und sich gefragt haben, ob ich das wirklich gelöst habe oder nicht, da hier keine Lösung akzeptiert wurde.
Die endgültige Lösung hat nichts mit Deserialisieren zu tun. Stattdessen wurde eine brandneue Kopie der Oracle-Datenbank OAP.NET vollständig deinstalliert und installiert Client, der Provider viele, wenn nicht alle unsere Anwendungen verwenden.
Aufgrund von anekdotischen Beweisen scheint dieses Problem auf falsch gepatchten Versionen von ODP.NET-Assemblys zu beruhen, die anschließend über virtuelle Maschinenklone auf andere Systeme übertragen wurden.
Wenn ODP.NET vollständig entfernt wurde und eine neue kompatible Version von der Oracle-Website abgerufen und installiert wurde, verschwand das Problem vollständig.
Die Hypothese ist, dass ein benutzbarer (aber korrupter) ODP.NET-Treiber unsicheren Code hat und den .NET geschützten Speicherbereich nach der ersten Verwendung wiederholt in der Nähe der Deserialize -Methode überschreibt. Wenn Deserialize vor irgendwelchen ODP.NET-Aufrufen aufgerufen wurde, würde es gut funktionieren. Alle nachfolgenden Aufrufe von Deserialize nach der Verwendung von ODP.NET-Aufrufe würden jedoch kläglich scheitern.
Die letzte Lösung, die nun in zwei verschiedenen Produkten zweimal gelöst wurde, ist, eine gute / frische / saubere / neue Kopie von ODP.NET zu installieren.
Nicht hübsch ... aber das hat es gelöst.
EDIT: Das war leider nicht die Lösung, aber es könnte anderen helfen, ein sehr ähnliches Problem aufzuspüren. Diese Antwort hier ist die tatsächliche Lösung.
Ich habe glaube Ich habe die Lösung für dieses Problem gefunden. Es ist ein Fehler in .NET 3.5 SP1 .
Die Serialisierung hängt oder löst eine OutOfMemoryException mit dem statischen Delegaten und ISerializable auf 3.5 SP1 aus (ID: 361615 ):
Wenn eine generische Klasse ISerializable implementiert und über ein statisches Delegate-Member verfügt, das die Argumente des generischen Typs verwendet, hängt die binäre Deserialisierung (auf einem 32-Bit-System mit Windows Server 2003) oder wirft eine OutOfMemoryException (auf einem 64 -Bit-System mit Windows Server 2008).
Dieser Fehler tritt bei .NET 3.5 SP1 auf und trat bei .NET 3.5 ohne SP1 nicht auf.
Die Lösung besteht darin, KB957543 Hotfix zu installieren.
Sie haben nicht genügend Details angegeben, um Ihr Problem neu zu erstellen. Aber der Leser implementiert IDisposable und sollte ordnungsgemäß entsorgt werden. Vorzugsweise durch Einwickeln in einen Benutzungsblock. Die meisten Entwickler stoßen nie auf ein Problem, wenn sie vergessen, etwas zu entsorgen, weil der Müllsammler schließlich das Chaos aufräumen wird. Es ist jedoch nicht schwer, etwas zu codieren, das Probleme verursacht, bevor der GC zur Säuberung kommt, oder sogar eine vollständige Säuberung verhindert.
%Vor%Basierend auf der Dokumentation der XmlSerializer-Klasse, die Sie zwischenspeichern sollten die XmlSerializers sonst können Sie schlechte Leistung oder einen Speicherverlust verursachen.
%Vor%Tags und Links .net serialization out-of-memory xmlserializer