Diskussion:Speicherleck

message: 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)

message: 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)
replies: text: 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)
thread_title:  Vergleich von Memory-Debugging Tools erwünscht? 

message: 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)
replies: text: 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)
thread_title:  Diverses  

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text:  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)
replies: text: 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)
replies: text:  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)

text:  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)
thread_title:  Problematik (Version von Andreas75) 

message: 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  (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)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  Diskussion aus dem [[WP:RVN|Review]] vom 29. September bis 28. Oktober 2006 

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

message: 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)
replies: text: 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)

text: 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)

text: 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)
replies: text: 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)
replies: text:  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)
replies: text:  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)
replies: text: 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)
replies: text:  "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)

text: 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)

text: 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)
thread_title:  verständnis... 

message: 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)
replies: text: ä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)
thread_title:  Halteproblem und Speicherleck 

message: 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)
replies: text: 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)

text: 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)

text: 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)
thread_title:  [[Speicherleck]] / halteproblem 

message: verschoben von einer user talk seite... daher etwas off-topic... --Heimschützenverein 18:41, 14. Jun. 2008 (CEST)
replies: text: 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)
replies: text:  ja... --Heimschützenverein 15:05, 14. Jun. 2008 (CEST)

text: Ja. --Cspan64 15:20, 14. Jun. 2008 (CEST)
thread_title:  [[Speicherleck]]: Haltet ein! 

message: Wieso ist der Abschnitt vorhanden wenn er keine Nachweise enthält?
--79.238.214.249 03:40, 2. Okt. 2012 (CEST)
replies: text: mach ihn doch selbst weg, wenns dich stört... WP:SM... --Heimschützenzentrum (?) 07:52, 2. Okt. 2012 (CEST)
thread_title:  Einzelnachweise 

message: Was war denn an dem Wort Heuristik so schlimm, dass es durch sonen konkreten Linux-Kram ersetzt werden musste? *lol* mach das mal einer/eine wieder weg... --Heimschützenzentrum (?) 21:32, 19. Jun. 2014 (CEST)
replies: text: Bevor ich darauf antworte, eine Frage: Gibt es irgendeinen Ausgang für diese sich anbahnende Diskussion bei der du nicht wieder am Ende meinst, dass man alles zurücksetzen sollte?--Plankton314 (Diskussion) 21:51, 19. Jun. 2014 (CEST)
thread_title: Lösungsmöglichkeiten / Linux

message: Ich habe den Abschnitt entfernt, da das darin enthaltene Beispiel und auch die weiteren Ausführungen dazu schlichtweg Quatsch waren. Wenn eine Referenz auf irgendwas out-of-scope geht, dann ist das referenzierte Objekt zum Abschuss durch den GC freigegeben. Siehe auch: http://www.c-plusplus.de/forum/327645
213.162.68.166 19:17, 28. Aug. 2014 (CEST)
replies: text: Ich habe es wieder reingegeben, da das Beispiel schlichtweg kein Quatsch ist. Ich habe es ein wenig verbessert, damit das Speicherleck auch noch existiert, nachdem die Methode aufgerufen wurde. --Sebastian.Dietrich  ✉ 21:04, 28. Aug. 2014 (CEST)

text: Es steht derzeit auch nirgends, dass ein Speicherleck zwingend nicht mehr erreichbar sein müsste, sondern nur, dass das Programm den Speicher nicht mehr freigibt.--Plankton314 (Diskussion) 21:17, 28. Aug. 2014 (CEST)
thread_title:  Beispiele: Automatische Speicherbereinigung (entfernt) 

message: – GiftBot (Diskussion) 07:56, 30. Nov. 2015 (CET)
thread_title:  {{Anker|deadurl_2015-10}} Defekter Weblink