Memoryleaks in .NET-Programmen?

[Exxtreme]

Ich dachte, das sei gar nicht möglich? Nun ja... ATi hat's anscheinend geschafft wenn Terry Makedon nicht gelogen hat. :D


[22:17:50] [@[R3D]MrB]: Why does CCC take so much memory lol sorry
[22:18:12] [+ATI_Linux_Guys]: Because we had a memory leak problem that will be fixed in the next CATALYST posting

Wie schafft man einen Memoryleak bei sowas zu produzieren?

[Gast]

ich denke sie speichern irgendwo unnütze pointer auf irgendwelche objekte, die dann einfach nicht freigegeben werden

[Demirug]

Indem man Objekte in irgendwelchen Bäumen, Listen usw miteinader verbindet und dann von einem davon eine Referenz hält. Dann müssen alle Objekte die irgendwie damit verbunden sind auch im Speicher gehalten werden.

Das ist kein Leak im klasichen Sinn hat aber die gleiche Auswirkung. Bei einem klasichen Leak wäre der Speicher ja für immer verloren. Bei einem GC kommt man immer wieder ran sobald die letzte Referenz auf die entsprechenden Objektstruktur doch noch den Kontext verlässt.

[HellHorse]

Indem man Objekte in irgendwelchen Bäumen, Listen usw miteinader verbindet und dann von einem davon eine Referenz hält.
Am besten in einer Klassenvaribale oder einem singelton :D

[grakaman]

Am besten in einer Klassenvaribale oder einem singelton :D

Demirug redet sicher eher von zirkulären Referenzen. Vielleicht greift das Control auch einfach nur auf unmanaged Code zurück, was für die Speicher Leaks verantwortlich ist.

[HellHorse]

Demirug redet sicher eher von zirkulären Referenzen.
Zikuläre Referenzen alleine sind eigentlich nur ein Problem falls man reference couting macht. Ich denke nicht, dass .NET damit Probleme hat.

Folgender zugegebenermassen ziemlich doofer Code zeit dass der Java GC keine Probleme mit ref cycles hat.

import java.util.concurrent.atomic.AtomicInteger;

public class GCTest {
private static final AtomicInteger refcount = new AtomicInteger(0);

public static void main(String[] args) {
for (int i = 0; i < 1000 ; ++i) {
new Head();
}
System.gc();
System.out.println("not killed cycles: "+refcount.intValue());
}

private static class Head {
private Object tail;

public Head() {
this.tail = new Tail(this);
refcount.incrementAndGet();
}


protected void finalize() throws Throwable {
refcount.decrementAndGet();
}
}

private static class Tail {
private Object head;

public Tail(Object head){
this.head = head;
}
}
}

Das unter der Voraussetzung, dass der Compiler nix wegoptimiert hat.

Aber gc ist ein grosses Thema mit vielen versch. Ansätzen die alle ihre Vor- und Nachteile haben.

[grakaman]

Zikuläre Referenzen alleine sind eigentlich nur ein Problem falls man reference couting macht. Ich denke nicht, dass .NET damit Probleme hat.


Damit hat ja .NET auch keine Probleme, ich habe das jetzt eher als allgemeines Problem bei Speicher Leaks verstanden. Aber zirkuläre Referenzen sind imo nicht nur Probleme beim Reference Counting, da auch beim normalen Löschen z.B, unter VB6 nur die Variable auf dem Stack gelöscht werden müsste, nicht aber das Objekt selbst, wenn ein anderes eben noch auf dieses verweist.

[Demirug]

Demirug redet sicher eher von zirkulären Referenzen. Vielleicht greift das Control auch einfach nur auf unmanaged Code zurück, was für die Speicher Leaks verantwortlich ist.

Ihr habt beide recht. Ich meinte eine Objektstruktur mit gegenseitigen Bezügen (gerne auch zirkuläre) welche durch eine globale Referenz im Speicher gehalten wird.

[Coda]

Da verspricht .NET immer ein einfacheres Speichermanagement und im Endeffekt wird es nur schwieriger weil man solche Sachen natürlich nicht gleich erkennt :rolleyes:

[Exxtreme]

Da verspricht .NET immer ein einfacheres Speichermanagement und im Endeffekt wird es nur schwieriger weil man solche Sachen natürlich nicht gleich erkennt :rolleyes:
Naja, das, was ATi da macht, scheint nicht eine übliche Vorgehensweise zu sein. Und ich denke, daß ATi das in den Griff kriegt.

Andererseits kann Fehlertoleranz zu Fehlern führen. Deshalb heisst es seit dem Untergang der Titanic: Mache deine Produkte robust aber prahle nicht damit. ;)

[Xmas]

Da verspricht .NET immer ein einfacheres Speichermanagement und im Endeffekt wird es nur schwieriger weil man solche Sachen natürlich nicht gleich erkennt :rolleyes:
Schwieriger nicht gerade, aber wenn man vergisst auf Object Lifetime zu achten und Referenzen zu löschen, wenn man sie nicht mehr braucht... "der GC machts ja" ;)