Out-Of-Memory Exception weil Drittanbieter-DLL Speicher nicht frei gibt

Hallo,

ich verwende eine DLL deren Quellcode mir nicht vorliegt.
Die DLL verarbeitet sehr große Bilder, für die ich nur den Pfad angeben kann. Hinterher wird leider nicht aufgeräumt und so bekomme ich früher oder später eine Out-Of-Memory-Exception, trotz allem Disposen und erzwungener GC.

Nun, ich bräuchte eine einfache, schnelle Workarround Lösung, wie ich den Speicher wieder freibekomme.

Mir fällt momentan nur Folgendes ein: Meine Programmteile, welche die DLL verwenden, komplett auslagern. Dann vom Hauptprogramm als Prozess aufrufen und diesen hinterher killen. Das ist aber auch mit Aufwand verbunden, u.a. wegen der Prozess-Kommunikation.

Hat jemand eine bessere Idee?

Danke

Ich fürchte Dir wird nichts anderes übrigbleiben.
Woher ist diese DLL? Schick einen Bug-Report an den Hersteller.

Zu wenig Information.

Welche Art dll?
- C# dll
- c++/cli dll
- native dll

Wie wird die dll benutzt?
- COM-Interop
- C# halt
- was?

Ausserdem. Ohne deinen Sourcecode zu kennen ist auch schwer zu beurteilen ob Du nicht doch einen Fehler machst der das Problem auslöst, wie z.B. eine Referenz auf Objekte halten die dadurch nicht abgebaut werden können. da nutzt dann auch die erzwungene GC nix (Die löst eh keine memory-leaks...)

hustbaer

Entnervter Programmierer schrieb:

Mir fällt momentan nur Folgendes ein: Meine Programmteile, welche die DLL verwenden, komplett auslagern. Dann vom Hauptprogramm als Prozess aufrufen und diesen hinterher killen. Das ist aber auch mit Aufwand verbunden, u.a. wegen der Prozess-Kommunikation.

Ich hätte dir genau das vorgeschlagen. Wobei du mit "killen" hoffentlich meinst dass sich der Prozess einfach hübsch selbst beendet.

Ansonsten: windbg anwerfen, sos.dll laden, und gucken was das Leak verursacht (vorausgesetzt es ist eine .NET DLL - sonst sieht's da etwas finster aus). Wenn du den Bug gefunden hast ruf beim Hersteller an und sag denen die sollen das fixen.

p.S.: bzw. du könntest dich trotzdem mal mit windbg auf die Suche machen, vielleicht leakt ja wirklich dein eigener Code.

Hallo ihr, was genau meint ihr unter "Prozess"? Aber keine "Thread" oder? Kann man so also mehre Process domainen miteinander agieren lassen? Datenaustauschen und so? gibt da ein simples Beispiel?

Nur rein aus Interesse;)

Rhombicosidodecahedron

hustbaer schrieb:

Entnervter Programmierer schrieb:

Mir fällt momentan nur Folgendes ein: Meine Programmteile, welche die DLL verwenden, komplett auslagern. Dann vom Hauptprogramm als Prozess aufrufen und diesen hinterher killen. Das ist aber auch mit Aufwand verbunden, u.a. wegen der Prozess-Kommunikation.

Ich hätte dir genau das vorgeschlagen. Wobei du mit "killen" hoffentlich meinst dass sich der Prozess einfach hübsch selbst beendet.

Ansonsten: windbg anwerfen, sos.dll laden, und gucken was das Leak verursacht (vorausgesetzt es ist eine .NET DLL - sonst sieht's da etwas finster aus). Wenn du den Bug gefunden hast ruf beim Hersteller an und sag denen die sollen das fixen.

p.S.: bzw. du könntest dich trotzdem mal mit windbg auf die Suche machen, vielleicht leakt ja wirklich dein eigener Code.

Meinst du nicht .Net Reflector? (da wahrscheinlich wenn im Debugmodus bei Fehlermeldungen doch der Stacktrace angezeigt wird und du so zur Wurzel allen Übels gelangen kannst)

EXDW

Ich würde den Fehler erst einmal auf der eigenen Seite suchen. Prüfen ob irgendwo noch Referenzen herum liegen wäre der erste Ansatz.

Es lag definitiv nicht an meinem Code: Sowas schließe ich notfalls immer durch runterbrechen auf kleine Testanwendungen aus. Außerdem habe ich garkeine Referenzen auf die Bilddateien. Die laden sich die Module alle selbst anhand von Pfadangaben.

Ich habe es jetzt in einen Prozess ausgelagert und schon gibt es nach dessen Ende keine Leaks mehr ... logischerweise.

hustbaer

Rhombicosidodecahedron schrieb:

hustbaer schrieb:

Entnervter Programmierer schrieb:

Mir fällt momentan nur Folgendes ein: Meine Programmteile, welche die DLL verwenden, komplett auslagern. Dann vom Hauptprogramm als Prozess aufrufen und diesen hinterher killen. Das ist aber auch mit Aufwand verbunden, u.a. wegen der Prozess-Kommunikation.

Ich hätte dir genau das vorgeschlagen. Wobei du mit "killen" hoffentlich meinst dass sich der Prozess einfach hübsch selbst beendet.

Ansonsten: windbg anwerfen, sos.dll laden, und gucken was das Leak verursacht (vorausgesetzt es ist eine .NET DLL - sonst sieht's da etwas finster aus). Wenn du den Bug gefunden hast ruf beim Hersteller an und sag denen die sollen das fixen.

p.S.: bzw. du könntest dich trotzdem mal mit windbg auf die Suche machen, vielleicht leakt ja wirklich dein eigener Code.

Meinst du nicht .Net Reflector? (da wahrscheinlich wenn im Debugmodus bei Fehlermeldungen doch der Stacktrace angezeigt wird und du so zur Wurzel allen Übels gelangen kannst)

Was für Fehlermeldung? Er hat ein Leak, das findest du im VS Debugger (leider) nicht so ohne Weiteres.
Ich meine das da:
http://msdn.microsoft.com/en-us/library/bb190764(VS.80).aspx