Diskussion:Speicherleck

Im Gegensatz zum Vorgängerartikel habe ich nun versucht, eine umfassende Begründung für die Memory-Leak-Problematik zu geben. Mathias 20:09, 20. Aug 2005 (CEST)

Vergleich von Memory-Debugging Tools erwünscht?

Ich würde mir wünschen, dass inm Abschnitt "Abhilfe" mehr erwähnt wird. Zum einen eine größere Auflistung von Tools. Zum anderen aber auch eine vergleichende Beschreibung der Tools. Ich könnte auch anfangen, da etwas zu schreiben, aber ich wollte erstmal fragen, ob das als "unüblich" gilt. Vorteil davon: Praktischere, umfasssendere Informationen.

Oft findet man bestenfalls nur geringfügig kommentierte Auflistingungen. Vorteile davon: Weniger Meinungsstreitereien, Wikipedia ist keine Computerzeitung. --Weidenrinde 08:50, 1. Nov 2005 (CET)

Perl weist durchaus Speicherlecks auf.

Perlprogramme können während der Ausführung durchaus Speicherlecks produzieren, das stimmt. Das Problem ist, dass eine automatische Speicherverwaltung schon theoretisch nicht in der Lage ist alle Eventualitäten zu berücksichtigen. Ich habe den Artikel daher etwas umformuliert und ergänzt. Mathias 19:20, 8. Jun 2006 (CEST)

Zum Edit-War

Zugegeben, der Artikel ist sprachlich nicht ausgereift. Allerdings ist es nicht wirklich zielführend, schlechte Formulierungen durch falsche (und sprachlich schlechte) Phrasen zu ersetzen.

"Wenn das Halteproblem lösbar ist...", dann wäre alles ganz toll. Aber es ist nicht lösbar (das ist keine Annahme, sondern bewiesen!). Auch andere Formulierungen wie "Speicher kann nicht oder nicht mehr benutzt werden" sind sprachliche Katastrophen! Ich überarbeite den Artikel noch einmal. -- Mathias bla? 15:14, 10. Sep 2006 (CEST)

1. Dass das Halteproblem nicht lösbar ist, ist keineswegs zutreffend, denn: Es ist semi-entscheidbar. Da wir im Artikel von einer konkreten Instanz des Halteproblems geschrieben haben, ist also meine Formulierung zutreffend. Es wäre vielleicht die Formulierung "immer dann wenn die konkrete Instanz des Halteproblems gelöst werden kann" besser.
2. Im übrigen vermag ich an der Formulierung "nicht oder nicht mehr" nichts schlechtes zu finden... Das wird auch von US Juristen so verwendet (etwa: "at or about at"; ich hatte da mal die Ehre einen solchen Schriftsatz zur Klageerhebung zu lesen)... Natürlich darfst Du auch aus dieser eleganten Konstruktion zwei riesen Satzteile bauen!
3. Zwei gleich benannte Überschriften sind natürlich völlig daneben! Besonders vom Sprachlichen her...
4. Meine Strukturierung in Problematik/Lösungsansätze war hervorragen - besonders im Vergleich zum jetztigen Zustand
5. Desweiteren ist das Abschweifen vom Thema auch keine gute sprachliche Eigenschaft (1. Kann man viel kürzer klarmachen, dass Speicher gebraucht wird; 2. was soll da die Rangfolge (zweitwichtigste)?).
6. "Die Sicht des Programmierers"!? Du meine Güte... Kindergarten? Außerdem könnte es genauso heißen: Die Sicht des Software Designers/Architekten oder Informatikers oder was weiß ich...
7. Was is mit meinem Verweis auf boehm-gc geworden? Ist boehm-gc schlecht (aus der Sicht des Programmierers)? Oder was?
8. Wieso soll man zweimal schreiben, dass mit dem Ende des Programms auch das Speicherleck ein Ende hat? Damit der Leser nach dem ganzen sprachlichen Terror beruhigt ist?
9. Ockhams Rasiermesser

Daher: Revert!

--213.54.83.34 17:13, 10. Sep 2006 (CEST)

1. "Im übrigen kann auch die einfache dauernde Beobachtung des Speicher-Anspruchs eines Programmes unter Berücksichtigung der gerade gegenwärtigen Arbeitsbelastung bei hinreichendem Wissen über die Natur des Programmes Aufschluss über das Vorliegen eines Speicherlecks hinreichenden Ausmaßes geben." - ist das verständlicher Stil?
2. "immer dann wenn das semi-entscheidbare Halteproblem in einer konkreten Instanz lösbar ist" - semi-entscheidbarkeit in Bezug auf das Halteproblem bedeutet, dass man herausfinden kann, dass ein Programm anhält, aber man kann nicht herausfinden, dass es nicht anhält. Und genau der letzte Fall ist für die Speicherleck-Problematik wichtig. Man kann nicht sicher beweisen, dass ein Programm ein Speicherleck provoziert. Offenbar beziehst du dich darauf, dass es in konkreten Fällen manchmal doch möglich ist - aber damit hat der Begriff "Instanz" in Bezug auf theoretische Informatik (die ist es ja, wenn man von "Halteproblem" spricht) nichts zu tun. Da meint der Begriff "Instanz", dass es in der Art der Problemstellung ein ähnliches Problem gibt. Es meint nicht einen konkreten Fall.
3. "Insoweit nur in begrenztem Maße Arbeitsspeicher zur Verfügung steht (auch virtueller Speicher ist begrenzt und bringt zudem Performance Einbußen mit sich), und insoweit Programme Teile des Arbeitsspeichers zur alleinigen Nutzung erhalten müssen, ist ersichtlich die sparsame Beanspruchung von Arbeitsspeicher wichtig für einen Störungs-armen Betrieb." - Was ist "Performance Einbuße"? Soll wohl verständlich sein - ich weiß nur nicht, für wen. Auch ist es nicht "insoweit" der Fall, dass nur eine begrenzte Menge von Arbeitsspeicher zur Verfügung steht. Es wird immer so sein! Auch wird es "insoweit" kein Programm geben, dass nicht Arbeitsspeicher zur alleinigen Nutzung erhalten muss. Und spätestens bei "Störungs-arm" dreht sich mir sprachlich der Magen um. Die Qualität dieser Version ist syntaktisch und grammatisch schlecht - verständlich macht sie dies sicherlich nicht. -- Mathias bla? 17:34, 10. Sep 2006 (CEST)

Ich habe Deinen Erguss mal besser formatiert...

1. Zu 1.: Ja! Was verstehst Du denn nicht? Auch lange Sätze können verständlich sein. Die einzelnen wesentlichen Aspekte sind in logisch korrekter Reihenfolge aneinandergereiht. Im übrigen kann ich als Dipl.(U)-Inf. sagen, dass ich selbst ebengenauso einmal ein Memoryleak entdeckt habe (man könnte nun natürlich noch sagen, dass das Programm, das dort immer weiter anschwoll, diesen zunehmenden Speicherbedarf durch die Bearbeitung von Schach-Aufgaben rechtfertigen konnte, aber auch das würde in meine "nutzen können" Formulierung fallen, weil der eigentliche Zweck dieses Programms ein ganz anderer gewesen ist).
2. Zu 2.: Auch zu der Formulierung mit "Instanz des Halteproblems" noch etwas (obwohl es unnötig ist): Natürlich hat auch das Halteproblem Instanzen (auch im Sinne der theoretischen Informatik), die durch eine konkrete Belegung der Variablen gegeben wären (Variablen wären: Programm-Text und Eingabe-Werte, wobei sich letztere sicherlich im Geiste der Korrektheitsbeweise durch Pre-Condition in allgemeiner Form angeben ließen). Das ist übrigens auch die Verwendung in Deinem Sinne, weil schließlich das allgemeine Halteproblem spezialisiert werden kann, indem man ein Programm fest vorgibt und nur die Eingaben in gewissem Maße frei lässt. Bitte etwas konstruktiver! geändert: --213.54.83.34 18:28, 10. Sep 2006 (CEST)
3. Zu 3.: "Performance Einbuße" ist ja fast schon allgemein verständlich: Es führt eben zu Verzügerungen und schlimmsten Falles zu sachlich falschen Ergebnissen (eingebüßte Performance eben).
4. Noch zu 3.: "Insoweit" bedeutet für mich (als Muttersprachler), dass das nochfolgende eben nur in dem Maße gilt, in dem es auch im konkreten Fall zutrifft (etwa ist auf einer Maschine mit 4GB es herzlich egal, ob da einer meint er müsse zehn Millionen Mal 8 Byte "malloc'en", ohne das Ergebnis jemals irgendwie zu verwenden, besonders wenn sein Programm das einzige ist, das laufen soll; die Menge des zur Verfügung stehen Arbeitsspeicher kann also in konkreten Fällen dermaßen groß sein, dass er keine reale Begrenzung darstellt; er ist also quasi unbegrenzt). Es soll ja gerade die Problematik erläutert werden und dazu muss man eben schon differenziert vorgehen.
5. Noch zu 3.: Doch! Es kann sehr wohl zwei Programme geben, die jeweils gegenseitig sowohl ihren Programm-Code als auch ihre Daten und meinetwegen auch Eingaben manipulieren (meinetwegen über Semaphore in geregelten Bahnen (das hat jetzt nichts mit Achterbahn zu tun) -- muss aber nicht sein...). Selbst modifizierender Code kann durchaus Sinn machen... Auch muss man nicht unbedingt von einem UNIX-artigen Betriebssystem ausgehen... Und dennoch kann der Begriff Speicherleck auch dort Sinn machen...
6. Noch zu 3.: "Störungs-arm": Ja und? Wenn sich Dir da der Magen umdreht, dann sicherlich nicht wegen dieser Vokabel. Darüber möchte ich mit Dir auch nicht reden, weil mir die Bestallung zum Arzt fehlt.
7. Noch zu 3.: Syntaktisch schlecht? Warum? Das heißt wohl Rechtschreibfehler oder wie?
8. Noch zu 3.: Grammatisch schlecht? In Deiner letzten Version von 15:25 seh ich einen Grammtik-Fehler gleich im ersten Satz: "der jedoch nicht mehr nutzbar." Da wolltest Du wohl das Prädikat einsparen... Toll!

Das war jetzt quasi mein Schlusswort in dieser Sache. Irgendwann wird es mir eben einfach zu blöd! Übrigens hast Du Dir nicht die Mühe gemacht, auf meine Kritik an Deiner Version von 15:25 einzugehen, so dass ich im wesentlichen von insgeheimer Zustimmung und ansonsten von gekränkter Eitelkeit ausgehe... Das ist jetzt also als Kapitulation zu werten. Schöne Grüße an Deinen Hausarzt! --213.54.83.34 18:22, 10. Sep 2006 (CEST)

Du hast dich gerade selbst entlarvt. -- Mathias bla? 19:25, 10. Sep 2006 (CEST)

Kannste/Willste das mal erläutern? Ich seh nämlich nicht, warum das zutreffen sollte... --213.54.83.34 19:39, 10. Sep 2006 (CEST)

Ergänzung zu meiner Kapitulation: Die Verantwortung für den jetztigen (verpfuschten) Zustand kann ich natürlich nicht übernehmen. 1. Die knappen, verständlichen Formulierungen sind teilweise sinnlos ausgedehnt worden ("im Allgemeinen theoretisch"); 2. Prozess statt Programm!? Warum??? 3. "reserviert"? Wo denn? 4. "Ausführungsproblemen"??? Hä? Duden? 5. "Fordert ein Prozes"? Wieso? Was ist wenn es 1000 gleiche Prozesse sind, die alle das selbe eine einzige Memory-Leak einmal ganz am Anfang haben? Ich dachte Du kennst Dich so toll mit Theorie aus? (<--War nich ernst gemeint.) 6. "zum Absturz"? Toll?! 7. NEIN! Meistens beendet nicht das Betriebssystem den Prozess, wenn er keinen Speicher mehr kriegt, sondern er sich selbst (z. B. liefert malloc dann NULL und nicht n SEGV)! 7. Unproblematisch? Ist nicht alles irgendwie n Problem? 8. Und dann nochmal wiederholt das GC nix nützt... 9. Was denn sonst für Sprachen??? 10. Und sie "existieren [...] zur Verfügung"! Danke!? 11. Und noch Latein: "a priori"; 12. Und noch die Gewissensfrage... 13. Aus ner Referenz (boehm-gc) wird n WebLink... 14. Das konkrete Vorgehen bei dem diagnostizieren des memleak durch Beobachtung wird nicht mehr erläutert, aber dafür ist "Beispiel" noch im Singular, obwohl es 2 sind... 15. I!!!! --213.54.83.34 20:40, 10. Sep 2006 (CEST)

Diverses

Für „so wird der anfordernde Prozess üblicherweise von Seiten des Betriebssystems beendet. Dadurch können jedoch auch unproblematische Prozesse betroffen sein.“ möcht ich bitte einen Einzelnachweis sehen. Ich glaube mich dunkel zu erinnern, dass diese Strategie von manchen Betriebssytemen (evt. Linux) angewandt wird, um bestimmte deadlocks bei memory overcommitment zu verhindern/aufzulösen. Das waren aber afair keine klassischen ENOMEM-Situationen. Meine Erinnerung mag mich aber täuschen.

„Insbesondere kann der Bereich nicht mehr vom Programm freigegeben werden, soweit nicht genaue Kenntnis über die Funktion malloc vorliegt.“–Hab hier gestrichen, das ist imo ein arg exotischer Sonderfall und solang Programme die Kenntnisse nicht spontan bei Bedarf evolutionieren, seh ich nicht so recht, was dem Leser dieser Hinweis bringen soll. —mnh·∇· 20:45, 25. Sep 2006 (CEST)

Ich hab da mal ein paar "tipp"fehler bereinigt und die semantik wieder hingebogen... Im übrigen beendet nicht das betriebssystem einen prozess, weil dessen speicheranspruch nicht erfüllt wurde (höchstens wenn der prozess auf einen ungültigen speicherbereich schreibend zugreifen will gibts n SEGV o.ä.; im übrigen kann das betriebssystem sich eine Reservere für sich selbst aufbewahren, so dass derartige gewaltakte des betriebssystems denkbar unsinnig und überraschend wären). --213.54.75.182 03:51, 26. Sep 2006 (CEST)

Problematik (Version von Andreas75)

Zur Version von Andreas75 ist zu sagen, dass die Problematik eines Speicherlecks ja die ist, dass Speicher reserviert wurde, aber nicht benutzt werden kann. Es gibt durchaus auch Programme die immer mehr Speicher anfordern, diesen aber auch benötigen. Führt ein solches Programm zum Aufbrauchen des gesamten Systemspeichers, so handelt es sich dabei ja nicht um ein Leck (es wurde kein Speicher verschwendet).

Ansonsten finde ich die Version deutlich aufgeräumter als die bisherige. Zum Thema Beispiele wäre es sicherlich auch eine Bereicherung des Artikels, wenn Anschauungsobjekte der Realität (gab es schon mal prominente Abstürze wg. fehlerhafter Software oder Programme, die heute noch nicht richtig funktionieren oder funktionierten?). -- Mathias bla? 21:16, 27. Sep 2006 (CEST)

Ich halte die Diskussion darüber, ob ein Prozess einen angeforderten Speicherbereich verwenden kann oder nicht für esoterisch. Ein Speicherleck entsteht, wenn kontinuierlich Speicherbelegt wird, dieser aber nicht mehr freigegeben wird. Ein Prozess, der kontinuierlich weiteren Speicher belegt, diesen irgendwie verwendet ohne ihn anschließend wiede freizugeben, hat eben ein Speicherleck. Ist eine Anwendung fehlerhaft programmiert, so ist es für den Anwender einerlei ob ein Speicherbereich gar nicht mehr verwendet werden kann oder der Speicherbereich nur falsch verwendet wird. -- Andreas75 11:10, 28. Sep 2006 (CEST)

Ich sehe durchaus einen Unterschied darin, ob ein Prozess seinen Speicherbereich nicht freigibt, weil er ihn noch weiter braucht oder ob er ihn nicht mehr freigibt, weil er es nicht mehr kann bzw. dies nicht oder fehlerhaft implementiert wurde (dieser letztere Aspekt könnte auch noch im Artikel erwähnt werden). Im ersten Fall kann das Problem möglicherweise nicht einfach aus der Welt geschafft werden. -- Mathias bla? 13:34, 28. Sep 2006 (CEST)

Ich glaube wir meinen das Selbe. Solange ein Prozess einen Speicherbereich noch benötigt, soll er ihn natürlich nicht freigeben (und es handelt sich auch nicht um ein Speicherleck). Wichtig ist nur, dass er es irgendwann tut. Wenn ein Prozess einen Speicherbereich nicht freigibt (also gar nicht, d.h. im kompletten Verarbeitungsablauf nicht), handelt es sich nach meinem Verständnis um ein Speicherleck. Wie ist es denn bei Java, dort gibt keine Speicherbereiche die nicht mehr verwendet werden können, dennoch lassen sich durch vergessene Objektreferenzen Speicherlecks erzeugen. -- Andreas75 14:28, 28. Sep 2006 (CEST)

Ich bin soweit einverstanden, allerdings müsste man sagen, dass er zumindest die Speicherbereiche freigibt, die er garantiert im Laufe seines Lebens nicht mehr benötigen wird. Speicher, der bis zum Ende der Lebenszeit nicht mehr freigegeben wird, muss ja nicht unbedingt ein Speicherleck sein. Dein Beispiel zu Java ist ein Beleg dafür, dass es ganz ohne manuelle Speicherverwaltung (zumindest nicht für einige Anwendungsgebiete) geht. Dies könnte man noch im Artikel nachtragen. -- Mathias bla? 15:36, 28. Sep 2006 (CEST)

Es ist schlechter Stil, noch dynamisch allozierten Speicher zu halten, wenn das Programm seine Beendigung anfordert, denn: Sobald das Programm von einem anderen Programm benutzt werden soll, hat man dann "den Salat"... --213.54.141.247 09:32, 17. Okt. 2006 (CEST)

Soso... "vergessene Objektreferenzen"... Wie interessant... Da ist user:Mpohl307 aber froh, dass er einen gefunden hat, der... Soweit ich weiß erstellen heutige Versionen der JavaVM einen kompletten Graphen aus Objekten und Referenzen und können so auch einen Referenz-Zykel, dessen Objekte zwar alle referenziert werden aber nicht länger vom Programm genutzt werden können, finden. Beispiel: BEGIN SuperDuper a,b; a.next = b; b.next = a; END --213.54.141.247 09:32, 17. Okt. 2006 (CEST)

Es gibt aber in Java auch Objektbäume, die zwar noch von Threads referenziert werden, jedoch nicht mehr vom Programm benötigt. Solche vergessenen Objekte kann die VM nicht als „vergessen“ erkennen. --jpp ?! 13:33, 17. Okt. 2006 (CEST)

Und was soll daran ein "Speicherleck" sein? Dann wäre ja auch ein Algorithmus, der mehr Speicher als unbedingt benötigt verwendet, in dieser Weise fehlerhaft (das dürften wohl die allermeisten Algorithmen sein, was die Definition "Speicherleck" relativ dumm aussehen ließe; ich denke, dass mit Speicherleck nur die wirklich pathologischen Fälle (also die in denen zwar Speicher den Konkurrenten entzogen wird, ohne dass dies beabsichtigt ist) gemeint sein können). Man muss hier schon ganz klar zwischen "benötigt" (Zeit-Effizienz, Absicht) und "verwendbar" (fehlerhaft / unbeabsichtigt) unterscheiden. In dem Sinne hätte auch ein Programm, das absichtlich massenhaft Speicher beansprucht ohne ihn oder die entsprechende Referenz je zu nutzen, kein Speicherleck, wenn es eben der Zweck des Programmes so erfordert. --213.54.138.212 16:28, 18. Okt. 2006 (CEST)

Tja, offenbar gibt es Speicherlecks im engeren und weiteren Sinne. Ein Prozess, der kontinuierlich Speicher anfordert, ohne ihn wieder freizugeben, hat nach meiner Begriffsdefinition ein Speicherleck. Und genau so etwas hatte ich in meinem obigen Java-Beispiel im Sinn. --jpp ?! 16:53, 18. Okt. 2006 (CEST)

Ich habe nocheinmal darüber nachgedacht. Es ist wohl so, dass man auch fehlerhafte Algorithmen (also welche, die Speicher beanspruchen, ohne ihn jemals wieder nutzen zu können) ein Speicherleck im eigentlichen Sinn haben. Ich werde das also in dem Abschnitt über "Automatische Speicherbereinigung" korrigieren. --213.54.146.76 10:34, 23. Okt. 2006 (CEST)

Oj je, da haben wir mit dem Benutzer 213.54.141.247 allem Anschein nach einen intimen Kenner der JavaGC gefunden, ich warte auf die Erleuchtung durch 213.54.141.247. Ich habe nachwievor kein Argument gefunden weshalb die einfache Definition Speicher wird belegt und im Programmablauf nicht mehr freigegeben nicht trägt. Ob und wie Speicher noch verwendete werden kann und ob dies effizient erfolgt, ist doch unerheblich. -- Andreas75 19:27, 2. Nov. 2006 (CET)

Das hat mit JavaGC nicht unbedingt zu tun. Vielleicht hilft ein Gegenbeispiel ohne automatische Speicherbereinigung: Es ist denkbar, dass am Anfang ein Speicherbereich beansprucht wird, der bis zum Ende des Programms benötigt wird (zum Beispiel als Signal für die Programm-Beendigung: Solange die Variable 0 ist, darf das Programm weiterlaufen, und sonst soll es sich beenden), ohne dass es sich um ein Speicherleck handelt, obwohl keine Freigabe erfolgt (die Freigabe erfolgt dann implizit mit dem Ende des Ablaufs; das ist zwar schlechter Stil und schwerer wiederzuverwenden). --AGBÜMMS 07:44, 3. Nov. 2006 (CET)

Ich finde, die automatische Freigabe des Speichers zum Programmende gilt nicht. Die erfolgt schließlich bei jedem Program, ob mit GC oder ohne. Dynamisch belegter Speicher muss schon wissentlich freigegeben werden, in dem einen Fall genügt es eben eine Referenz auf null zu setzten, in dem anderen Fall muss eben delete aufgerufen werden. -- Andreas75 10:51, 3. Nov. 2006 (CET)

Hmm... Der krankhafte Charakter des Speicherlecks kommt aber in dem Fall nicht so richtig zum Vorschein. Umgekehrt: In dem 3. Beispiel (in Pseudocode formuliert) liegt ein dickes Speicherleck vor, obwohl aber am Ende die Freigabe regulär erfolgt (z. B. über die garbage collection). Daher ist fehlende Freigabe von Speicher irgendwie kein hinreichendes Kriterium (wohl aber ein notwendiges Kriterium häufiger Umstand). --AGBÜMMS 11:07, 3. Nov. 2006 (CET)

Ich frage mich gerade, ob die Definition dahingehend abgeändert werden sollte, dass nur diejenigen Fälle als Speichleck gesehen werden können, in denen der Speicherbedarf aufgrund des Fehlers ständig anwächst. --AGBÜMMS 11:12, 3. Nov. 2006 (CET)

Diskussion aus dem Review vom 29. September bis 28. Oktober 2006

Der Artikel leidet etwas unter dem user:Mpohl307 und ich sehe mich nicht in der Lage dem noch etwas entgegen zu setzen. Der MPohl307 zweifelt einerseits öffentlich meine Qualifikation [1] (Dipl.(U)-Inf.) an und verheddert sich dann selbst sprachlich (insbesondere beim Satzbau) und besonders fachlich (etwa erkennt er nicht, dass wir von Instanzen schreiben, und dass "lösbar" und "nicht entscheidbar" und "semi-entscheidbar" ohne Weiteres alles unterschiedliche Bedeutung haben kann); sodann muss man sich nicht nur seine Hasstiraden über meine angeblich unzureichende Qualifikation zu Gemüte führen, sondern auch noch dann seine seiner Meinung nach bessere/überarbeitete Version ansehen... Meine Frage nach seiner Qualifikation beantwortet der nicht, so dass ich mal aus den Symptomen schließen will, dass er recht jung, unangemessen arrogant und dazu auch noch recht ungebildet ist. Konkret steht insbesondere die Frage zur Diskussion, ob man beweisen kann, dass ein Programm ein Speicherleck provoziert (ich sage "Ja"; er sagt in der Diskussion "Nein" respektive "nicht", widerspricht sich im nächsten Satz selbst (offenbar meint der, dass es Teil-Programme/Funktionen/Prozeduren geben kann, von denen man unter Umständen nicht in endlicher Zeit sagen kann, dass sie niemals terminieren, so dass dann eben unter Umständen bestimmte Speicherbereiche niemals wieder genutzt werden, was einem Speicherleck entspräche) und führt aber gleichzeitig im Artikel unter "Beispiel" gleich zwei konstruktive Gegenbeweise). Auf jedenfall enthält der Artikel derzeit noch einen dicken Satzbau Fehler, den ich aus Angst vor weiteren Attacken nicht zu korrigieren wage. Näheres auf der Diskussions Seite: talk:Speicherleck --213.54.77.217 23:22, 23. Sep 2006 (CEST)

Ich gebe dir in dem Punkt recht, dass der Artikel meilenweit davon entfernt ist, als zufriedenstellend zu gelten. Es möge sich jeder Leser aber sein eigenes Bild davon machen, warum ich viele Teile der Edits revertiert habe (als Einstiegspunkt kann dies hier dienen). Den Unterschied zwischen einem Programm (im Endeffekt eine Abfolge von Befehlen) und einem Prozess (Programm in Ausführung) sollte man beispielsweise nicht vergessen (dieser Unterschied war/ist nämlich nicht jedem klar). Mit der Hoffnung, einen besseren Artikel zu erhalten... -- Mathias bla? 11:29, 24. Sep 2006 (CEST)

Es ist zunächst auffällig, dass dieser angeblich bzgl. "Speicherleck" wesentliche Unterschied zwischen Prozess und Programm erst auffiel, als ich wirklich wesentliche Änderungen vornahm. Bzgl. Speicherleck ist es nämlich unerheblich, ob der Quell-Code respektive sein Compilat gerade tatsächlich ausgeführt wird oder nicht, er enthält schließlich das Speicherleck in abstrakter Form (nämlich als fehlerhaften Quellcode); dies ist nicht nur umgangssprachlich korrekt sondern besonders auch gemäß der Definition in der Wikipedia (Leck): Es ist eben die Stelle gemeint, an der der Fehler ist, also an der das Unerwünschte passieren kann. Hier ist deutlich zu erkennen, der user:Mpohl307 nur aufgrund persönlicher Abneigung oder aber weil er sein Unvermögen nicht erkennen kann aber nicht aus sachlichen Gründen über mich schimpft. --213.54.77.217 16:22, 24. Sep 2006 (CEST)

Angesichts dieser Einleitung: was genau bezweckt ihr mit diesem Review? Die Klärung der unter euch strittigen Fragen oder allgemeine Verbesserungsvorschläge? Ein Review im eigentlichen Sinne ist nur sinnvoll, wenn die Hauptautoren zusammenarbeiten und sich in den grundlegenden Fragen einig sind. Diese Seite dient nicht dazu, persönliche Fehden auszutragen oder Streitfragen zum Artikel zu klären. Für letzteres ist die Diskussionsseite des Artikels da, und erstes könnt ihr woanders machen... -- Sdo 00:05, 7. Okt 2006 (CEST)

Da habe ich wohl den Sinn des Review-Prozesses falsch verstanden... Ich dachte, der Grund für das "nicht Weiterkommen" sei beliebig... Ich denke man sieht ganz deutlich, dass dieser Grund nicht in meiner Person oder meiner Qualifikation zu finden ist. Jetzt hat der user:Mpohl307 einen gefunden, der ihm offenbar Wohlgefälliges über "vergessene Objektreferenzen in Java" ins Ohr säuselt. Ich denke nicht, dass soetwas nötig ist. --213.54.141.247 09:24, 17. Okt. 2006 (CEST)

Beispiel in C++

Meiner Meinung nach ist es so, dass delete trotzdem den ganzen Speicher freigibt, aber delete[] auch die Destruktoren für alle Instanzen aufrufen würde (was in diesem Fall unsinnig wäre, da wir ja mit ints arbeiten (aber trotzdem geschrieben werden sollte)). Ich finde (falls ihr meinen Eindruck bestätigen könnt), dass das Beispiel unsinnig ist, da dadurch kein Speicherleck entsteht, sondern es eher ein schlechter Stil ist.

Pitcheraider 84.62.147.18 08:35, 22. Mär. 2007 (CET)

P.S.: Doch, ich bin mir sicher. New hat ja als "versteckten" Parameter ein size_t size, also allokiert es den Speicherbereich als ganzes. Delete gibt also auch den ganzen Bereich wieder frei. Delete[] ist wie bereits gesagt nur bei einem Zeiger auf mehrere Klassen notwendig, da sonst (bei delete) nur der Destruktor der 1. Klasse aufgerufen wird.

Pitcheraider 84.62.147.18 08:58, 22. Mär. 2007 (CET)

Also ich würde dir da mal zu stimmen new int i[5] erzeugt einen zusammenhängenden Speicherbereich, der mit delete einfach freigegeben werden kann. Anders sieht es bei Objekten aus. Wenn man ein Array von Objekten hat und dieses Array freigeben möchte reicht zwar auch dafür ein normales delete -- ABER es wird nur für das erste Objekt der Destruktor aufgerufen. Deshalb braucht man delete [], dass für alle Objekte des Arrays der Destruktur aufgerufen wird. Werde mal das Beispiel korregieren. --AndreasH 23:38, 28. Mai 2007 (CEST)

Automatische Speicherbereinigung

Siehe auch Benutzer_Diskussion:Heimschützenverein#Speicherleck. Membeth 13:40, 12. Nov. 2007 (CET)

Bitte verständlicher!

Bitte drückt Euch mal etwas klarer aus. Der Artikel ist schwer lesbar. Besser ist da die englische Version. --AlfonsGeser 18:00, 13. Jun. 2008 (CEST)

Ich halte den englischsprachigen Artikel für unqualifiziert, da er die automatische Speicherbereinigung an Programmiersprachen (und dann auch noch an C-basierten) und Referenzzählung festmacht. In echten objektorientierten oder gar parallel genutzen Laufzeitumgebungen ist soetwas gar nicht anwendbar (siehe zum Beispiel .NET, Java Runtime Environment, Windows Presentation Foundation etc.). Hier funktionieren nur Speicherbereiniger mit Scan- und Mark-Phasen, die voll in die Laufzeitsysteme integriert sind. Hier ist es unerheblich, welche Programmiersprache verwendet wurde, wenn diese nur hinreichend strukturiert und sicher ist, was bei C und C++ nicht der Fall ist.

Ich würde den englischsprachigen Artikel also lieber nicht als Vorbild nehmen. Ungeachtet dessen kann auch der deutschsprachige Artikel sicherlich verbessert werden. Membeth 18:21, 13. Jun. 2008 (CEST)

Man muss nicht alles aus dem englischen Artikel übernehmen. Fällt denn die automatische Speicherbereinigung überhaupt in die Zuständigkeit des Artikels Speicherleck? Speicherlecks entstehen durch die fehlende manuelle Freigabe des nicht mehr erreichbaren Speichers. Wenn eine automatische Speicherbereinigung aktiv ist, können gar keine Speicherlecks auftreten. Oder sehe ich das falsch? --AlfonsGeser 21:03, 13. Jun. 2008 (CEST)

ach je... auch bei automatische Speicherbereinigung können speicherlecks entstehen (z b wenn der bereich in dem die freigabe (implizit) erfolgen würde, nicht erreichbar ist)... das ist wichtig zu wissen... und sollte nich gelöscht oder versteckt werden... --Heimschützenverein 21:22, 13. Jun. 2008 (CEST)

verständnis...

falsch ist nicht verständlicher... einleitungen sollen kurz sein... für die implikationen is ja später noch platz... im übrigen: WP:Q... --Heimschützenverein 15:03, 14. Jun. 2008 (CEST)

Von folgender Passage in der Einleitung ist hier die Rede. Ich hatte sie hineingenommen, Heimschützenverein wieder gelöscht. Quelle: englische Version.

Durch wiederholte Verschwendung von Speicherplatz kann schließlich der verfügbare Arbeitsspeicher knapp werden.
Dadurch kann die Leistung des Computers abnehmen, oder sogar ein Absturz verursacht werden.

Der Begriff Speicherleck ist insofern irreführend, als der Speicher nicht tatsächlich verloren ist. Es handelt sich
nur um Speicher, der nicht mehr zugänglich ist.

Das ist zu lang für eine Einleitung? Irreführend? Gar falsch?

Ich zitiere aus Wikipedia:Wie schreibe ich gute Artikel:

Unmittelbar darauf sollte eine kurze Einleitung mit einer Zusammenfassung der wichtigsten Aspekte des
Artikelinhalts folgen. Die Einleitung sollte dem Leser einen kurzen Überblick über das Thema ermöglichen und für
sich genommen bereits das Lemma ausreichend erklären.

Ich bitte um eine überzeugende Begründung der Löschung oder um Wiedereinfügung der Passage. --AlfonsGeser 15:41, 14. Jun. 2008 (CEST)

die englische wikipedia ist keine quelle gemäß WP:Q... dann noch zu der analogie: ein leck im wassereimer: das wasser sei der speicher, der eimer die programme, das loch im eimer das speicherleck im programm, das durch das loch ausströmende wasser der speicher der verloren ist... nur weil der verlorene speicher durch das prozess-ende einfacher "einfüllbar" ist, als das wasser, das bereits im boden versickert ist, ist dieser begriff mal nich irreführend... --Heimschützenverein 15:53, 14. Jun. 2008 (CEST)

die implikationen des speicherlecks kommen dann ja in dem ersten abschnitt: "problematik"... mit dem begriff "verschwendung" bin ich auch nich glücklich, da er mir zu emotional ist... --Heimschützenverein 15:53, 14. Jun. 2008 (CEST)

Emotional besetzt finde ich "Verschwendung" nicht. Eine Waschmaschine kann zum Beispiel Wasser verschwenden. Das ist eine sachliche Feststellung. Um ein Urteil handelt es sich wohl, aber dasselbe Urteil steckt bereits im Begriff "Leck". Aber Du kannst gerne einen alternativen Begriff vorschlagen. Was den Vergleich betrifft: Der Eimer verliert das Wasser, das Programm verliert aber den Speicher nicht. Der Vergleich hinkt. Mir haben übrigens schon viele Leute gesagt, dass sie den Begriff Speicherleck für irreführend halten, ohne dass ich sie darauf angesprochen habe. --AlfonsGeser 16:25, 14. Jun. 2008 (CEST)

hm... "verschwendung" is, jedenfalls wenn man mit öko-spinnern aufgewachsen ist, mit existenz-ängsten behaftet... das programm verliert den speicher aber auch, weil er schließlich nicht mehr von nicht vorhandenem speicher unterscheidbar ist... noch ein erklärungsversuch: "das leck im schiffsrumpf: schwindender auftrieb = schwindender speicher + lenz-pumpe=prozess-ende + lenz-pumpe kaputt = schiff gaputt = gombjuda putt" --Heimschützenverein 16:54, 14. Jun. 2008 (CEST)

Du bist wohl der einzige, der Verschwendung mit Existenzängsten assoziiert. Verschwendung bezeichnet grundsätzlich völlig neutral die übermäßige / unsachgemäße Nutzung von Ressourcen, in diesem Fall die unnötige Auslastung der Speicherressourcen. Daher völlig korrekte Verwendung. Gruß aus dem Münsterland, -- Yellowcard 17:13, 14. Jun. 2008 (CEST)

Danke, Yellowcard. Heimschützenverein, sieh es doch mal so: Wir tun den Omas unter den Lesern einen Gefallen, wenn wir sie auf ein mögliches Mißverständnis hinweisen. Falsch kann das doch nicht sein, oder? --AlfonsGeser 18:25, 14. Jun. 2008 (CEST)

"mögliches Mißverständnis"? Mißverständnisse sind imma möglich... versteh ich nich... ohne quelle jedenfalls nich... da kann man nur paraphrasieren... und auch das sollte n guten grund haben (ich find den alten zustand jedenfalls nich schlechter...)... --Heimschützenverein 18:31, 14. Jun. 2008 (CEST)

ich musste den rest auch noch rückgängig machen, weil er offensichtlich falsch war... siehe edit kommentar... --Heimschützenverein 18:37, 14. Jun. 2008 (CEST)

Heimschützenverein, an meinem Edit war gar nichts falsch. Wir reden von folgender Passage:

Der Begriff Speicherleck (gelegentlich auch Speicherloch, englisch memory leak oder kurz memleak)
kommt aus der Informatik. Ein Speicherleck ist eine unbeabsichtigte Verschwendung von Speicherplatz durch ein
Computerprogramm, das einen Speicherbereich belegt, auf ihn jedoch nicht mehr zugreifen
kann.

Deine Begründung im Edit-Kommentar war wörtlich:

so war das falsch, weil: dann hätte ja jedes program n memleak, nämlich zwischen dem letzten zugriff und der
freigabe... in welcher informatik vorlesung hört man solche begriffe?

Zunächst möchte Dich in aller Form dazu auffordern, Deine Aktionen künftig mit den Betroffenen (also mir in diesem Fall) abzustimmen. So wie Du Dich im Augenblick benimmst, kann von Zusammenarbeit keine Rede sein. Wenn sich das nicht bessert, werde ich einen Vermittler beantragen.

Zweitens ist für Diskussionen die Diskussionsseite da, nicht der Edit-Kommentar. Wenn Du nicht verstehst, was ich gesagt habe, dann gibt es einen guten Grund, darüber zu reden. Schließlich möchte ich auch verstanden werden.

Drittens ist Deine Begründung unvollständig und nicht nachvollziehbar. Zwischen dem letzten Zugriff und der Freigabe kann das Programm noch auf den Speicherbereich zugreifen. Die Freigabe beweist das. --AlfonsGeser 19:06, 14. Jun. 2008 (CEST)

1. ich auch... konservativ is immer gut... du bist ja der, der dauernd was ändert... 2. es war ja ne begründung... war also ok... 3. die freigabe stellt keinen zugriff dar... und nochmal nachdenken: nach dem letzten zugriff kommt naklar keiner mehr sonst wärs ja nich der letzte... manno!!! --Heimschützenverein 19:30, 14. Jun. 2008 (CEST)

Folgende Diskussion aus Benutzer_Diskussion:Cspan64 wurde von Heimschützenverein hierhin kopiert. --AlfonsGeser 19:06, 14. Jun. 2008 (CEST)

Halteproblem und Speicherleck

Hallo Cspan64. Es geht um die Passage, die Du in Speicherleck wieder reingenommen hast:

Im allgemeinen Fall ist dieses Problem verwandt mit dem Halteproblem und wie dieses nur
semi-entscheidbar, da die Frage der Erreichbarkeit bestimmter Programm-Bereiche,
in denen etwa doch noch die Freigabe und besonders auch die Nutzung der fraglichen Speicherbereiche erfolgen
kann, zu untersuchen ist.

Der Grund, warum ich diese Passage aus dem Artikel gelöscht habe, ist folgender. Das Problem, von dem die Rede ist, ist nicht formal definiert. Damit ist auch keine formale Aussage über Entscheidbarkeit möglich. Du kannst mich natürlich gerne vom Gegenteil überzeugen. --AlfonsGeser 21:11, 13. Jun. 2008 (CEST)

ähm? das halteproblem ist schon definiert... es geht dabei darum, dass eine turingmaschine über eine andere nicht unbedingt sagen kann, ob sie terminiert... stichwort: endlosschleife... man kann also z.b. über ein programm, das durch ausprobieren eine lösung für die gleichung aus "Großer fermatscher Satz" mit einem hinreichend dämlichen n sucht, nicht unbedingt sagen, ob es überhaupt mit dem ergebnis "es gibt gar keine lösungen" anhält (nämlich ist es wohl erst in den 90er gelungen, zu zeigen, dass so ein programm nicht halten kann, weil es keine lösung gibt...)... ich hoffe jetzt isses verständlicher geworden... mit den speicherlecks isses auch so: keiner kann sagen, ob bestimmte speicherbereiche jemals wieder von einem bestimmten (existenzquantor - es muss schon ein besonders gemeines programm sein...) programm benutzt werden... --Heimschützenverein 10:04, 14. Jun. 2008 (CEST)

nachdem jetzt allseits konsens in dieser frage herrscht, habe ich alles wieder hingebogen... komm mir zwar etwas wie monk (Fernsehserie) vor, aber besser is das... in zukunft bitte vorher hier gewünschte änderungen zur diskussion stellen, da das thema offenbar schwierig ist... --Heimschützenverein 18:46, 14. Jun. 2008 (CEST)

Speicherleck / halteproblem

nicht nur die Formale Verifikation ist verwandt mit dem halteproblem, sondern auch die frage, ob ein bestimmter zeiger nocheinmal benutzt wird... oda? können wir den absatz bitte wieder zurück verschieben? --Heimschützenverein 21:19, 13. Jun. 2008 (CEST)

Es geht mir nicht um die Stelle, sondern um die Behauptung. Wir müssen uns darauf einigen, von welchem Problem genau die Rede ist.

• Variante 1 (statische Variante):

Gegeben: Ein Speicherbereich (durch Anfangs- und Endadresse), eine Programmposition.
Frage: Gibt es im Programm nach dieser Programmposition noch eine Zeigerkette, die zu diesem Speicherbereich führt?

Die Existenz der Zeigerkette ist ja gleichbedeutend mit der Erreichbarkeit des Speicherbereichs. Diese Variante bezieht sich auf den Programmtext.

• Variante 2 (dynamische Variante):

Gegeben: Ein Speicherbereich (durch Anfangs- und Endadresse), ein Programmzustand (Programmposition und Speicherinhalt).
Frage: Gibt es im Programmlauf zu diesem Zeitpunkt noch eine Zeigerkette, die zu diesem Speicherbereich führt?

Diese Variante bezieht sich auf den Zustand Zustand des Programmlaufs. Es gibt noch weitere Möglichkeiten. --AlfonsGeser 22:28, 13. Jun. 2008 (CEST)

ehm? das problem ist, dass bei bestimmten programmen nicht so einfach (also schon gar nicht automatisiert) gesagt werden kann, ob bestimmte programmteile jemals zur ausführung kommen können... und diese frage is fast dieselbe wie im halteproblem... --Heimschützenverein 10:43, 14. Jun. 2008 (CEST)

Danke. Ich glaube, Du meinst folgendes Problem:

Variante 3:

Gegeben: Ein Programm.
Frage: Gibt es eine Eingabe, sodass das Programm ein Speicherleck produziert?

Insofern hast Du recht: Dieses Problem ist unentscheidbar. Man kann nämlich das Äquivalenzproblem

Gegeben: Programme P und Q.
Frage: Liefern P und Q für jede Eingabe dasselbe Ergebnis?

auf das Speicherleckproblem reduzieren. Dazu bildet man das Programm:

Eingabe: x.
Falls P(x) /= Q(x), dann produziere ein Speicherleck.

Wenn das Speicherleckproblem entscheidbar wäre, dann hätte man so ein Entscheidungsverfahren für das Äquivalenzproblem, ein Widerspruch. Also ist das Speicherleckproblem unentscheidbar.

Wenn ihr Eure Passage entsprechend umformuliert, habe ich keine Einwände mehr. Alles Gute! --AlfonsGeser 12:35, 14. Jun. 2008 (CEST)

ich sehe keinen grund für eine umformulierung... es geht hier zweifellos um die frage der erreichbarkeit bestimmter programmbereiche und nicht darum komische notationen zu verwenden... --Heimschützenverein 14:19, 14. Jun. 2008 (CEST)

Speicherleck: Haltet ein!

verschoben von einer user talk seite... daher etwas off-topic... --Heimschützenverein 18:41, 14. Jun. 2008 (CEST)

Sorry, ich hatte übersehen, dass zu diesem Thema schon eine lange Debatte auf Diskussion:Speicherleck existiert. Ich hatte den Text wieder hereingenommen, weil mir die Similarität zwischen Memory leakage und dem Halteproblem plausibel erscheint. Und ich hatte ihn in den anderen Abschnitt kopiert, weil er dort m.E. thematisch besser passte, als da, wo er vorher stand.

Von mir aus diskutiert und entscheidet, was damit geschehen soll - ich werde mich dazu nicht aus dem Fenster lehnen. Ich hatte nur befürchtet, der an sich interessante Ansatz könnte vergessen gehen, wenn er ganz gelöscht wird - wie gesagt, ich hatte versäumt, die bereits vorhandene Diskussion dazu anzuschauen. Frohes Editieren! :-) --Cspan64 14:22, 14. Jun. 2008 (CEST)

Seid ihr damit einverstanden, dass ich diese Diskussion nach Diskussion:Speicherleck kopiere und dass wir die Diskussion dort weiterführen, damit der Rest der Welt daran auch teilhaben kann? --AlfonsGeser 14:54, 14. Jun. 2008 (CEST)

ja... --Heimschützenverein 15:05, 14. Jun. 2008 (CEST)

Ja. --Cspan64 15:20, 14. Jun. 2008 (CEST)

Ende der Kopie aus Benutzer_Diskussion:Cspan64. --AlfonsGeser 19:36, 14. Jun. 2008 (CEST)

Halteproblem immer noch

Zu der Halteproblem-Passage habe ich nach wie vor meine Einwände. Nachdem wir darüber diskutiert haben, ist hier ist mein konkreter Vorschlag zur Umformulierung:

Das statische Speicherleckproblem
 Gegeben: Ein Programm.
 Frage: Gibt es eine Eingabe, sodass das Programm ein Speicherleck erzeugt?
ist unentscheidbar, denn das Äquivalenzproblem lässt sich darauf reduzieren.

Was haltet ihr von dieser Version, Cspan64 und Heimschützenverein? Akzeptabel? --AlfonsGeser 20:17, 14. Jun. 2008 (CEST)

abgelehnt, weil: die notation is unverständlich und der vorschlag ist insgesamt weniger präzise als das was jetzt ist (semi-entscheidbar hört sich doch gleich freundlicher an)... welchen grund gibt es denn, von dem halteproblem abzurücken? religiöse etwa? --Heimschützenverein 20:39, 14. Jun. 2008 (CEST)

Das Speicherleckproblem ist eben nicht semi-entscheidbar. Oben habe ich bewiesen, dass es mindestens so schwer ist wie das Äquivalenzproblem. In Schönings Vorlesungsskript Informatik IV steht auf Seite 100 wörtlich:

Es gibt durchaus algorithmische Probleme, die noch "unlösbarer" sind als das Halteproblem, etwas das
Äquivalenzproblem für Turingmaschinen (...)

Falsche Behauptungen gehören nicht in die Wikipedia. Die Notation ist übrigens Standard in der Theoretischen Informatik. Wenn Du damit ein Problem hast, dann besuche mal eine Vorlesung oder halte Dich aus der Diskussion raus. --AlfonsGeser 10:13, 15. Jun. 2008 (CEST)

Standard? hängt ja wohl vom dozenten ab... außerdem soll der artikel gerade auch für pre-graduierte lesbar sein... es ist für mich nich anschaulich klar, wieso das speicherleck nicht semi-entscheidbar sein sollte, weil ja stets nur die frage zu klären ist, ob die freigabe-sequenz (analog zum programmende-sequenz) erreicht wird (ich setze einmal voraus, dass überhaupt freigabe-sequenzen vorhanden sind...)... im übrigen sieht es für mich so aus als ob deine WP:TF fehlgeschlafen ist, wobei die ohnehin gegen WP:Q verstößt... --Heimschützenverein 11:51, 15. Jun. 2008 (CEST)

Vorschlag: Wir nehmen den Abschnitt raus, bis jemand aus einem Fachbuch belegt, dass die Speicherleck-Frage semi-entscheidbar ist oder sich auf das Äquivalenz-Problem (das kannte ich noch gar nicht) reduzieren lässt. --Eike 09:47, 17. Jun. 2008 (CEST)