Diskussion:Speicherleck

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)

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)

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)

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

Was für ein Quatsch. ISO/IEC 14882:2011, § 3.7.4.2.3:

"[...] the behavior is undefined if the value supplied to operator delete(void*) in the standard library is not one of the values returned by a previous invocation of either operator new(std::size_t) or operator new(std::size_t, const std::nothrow_t&) in the standard library, and the behavior is undefined if the value supplied to operator delete[](void*) in the standard library is not one of the values returned by a previous invocation of either operator new[](std::size_t) or operator new[](std::size_t, const std::nothrow_t&) in the standard library."

Das Verhalten ist undefiniert! Eine Implementierung darf alle dtors aufrufen, deinen Rechner abfackeln, oder auch eine Pizza bestellen ... --194.118.51.150 04:03, 13. Jun. 2014 (CEST)Beantworten

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

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

"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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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

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)Beantworten

ä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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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

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)Beantworten

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)Beantworten

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

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

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

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

och nö... hier (pdf) hab ich was gefunden... scheint n vorlesungs skript zu sein... folie 22 soll mal als beleg für den status quo dienen... ich pfleg es mal ein... stand der forschung... --Heimschützenverein 13:42, 17. Jun. 2008 (CEST)Beantworten

Sieht mir gut aus - Alfons? --Eike 19:01, 17. Jun. 2008 (CEST)Beantworten

Mir nicht. Skripten sind im Allgemeinen nicht die zuverlässigsten Quellen. Dieses Skript hat nicht mal einen Autor. Aber um der Diskussion willen: Auch in dem Skript ist nicht genau beschrieben, welches Problem eigentlich unentscheidbar sein soll. Von Semi-Entscheidbarkeit ist nicht die Rede. Und das Halteproblem wird nur aufgeführt, weil es auch ein unentscheidbares Problem ist. --AlfonsGeser 12:43, 18. Jun. 2008 (CEST)Beantworten

ich kenne mich ja mit theologretischer informatik nich mehr so aus, aber hier in der wikipedia sind seit langem unangefochtene edits wohl nur durch quellen gemäß WP:Q zu stürzen... änderungen an stabilen versionen bedürfen also stets einer quelle... so eine quelle sehe ich nich... es ist doch unbestreitbar so, dass es konkrete instanzen des speicherleck-problems gibt, die entscheidbar sind... andererseits ist nicht bestreitbar, dass es nicht entscheidbare instanzen des speicherleck-problems gibt... daraus ergibt sich doch anschaulich sofort die semi-entscheidbarkeit...? oda? --Heimschützenverein 13:53, 18. Jun. 2008 (CEST)Beantworten

Soory, Alfons, da hab ich zu ungenau hingeschaut. Also haben wir derzeit keine Quelle für eine Semi-Entscheidbarkeit. Ich hab den Absatz rausgenommen. --Eike 21:28, 23. Jun. 2008 (CEST)Beantworten

ähm? ein skript reicht also nich? in skripten sollte ja wohl der unumstrittene stand der forschung zu finden sein, damit nich n haufen durchgeknallter absolventen auf die wirtschaft losgelassen wird... jedenfalls besser als die TF, die derselbe user hier für tauglich hielt... also soll der wichtige hinweis auf die semi-entscheidbarkeit fehlen? was ist denn wenn einer meint, die automatische speicherbereinigung beseitige das problem? --Heimschützenverein 21:40, 23. Jun. 2008 (CEST)Beantworten

Ich finde, Uni-Folien sollten reichen, wenn nichts Besseres da ist. Aber wie Alfons so richtig bemerkt: Da steht nichts von Semi-Entscheidbarkeit. Die Folien sind da überhaupt so ungenau, dass ich vorschlagen würde, sie nicht zu einem Satz im Artikel zu verwursten. --Eike 22:54, 23. Jun. 2008 (CEST)Beantworten

dann einigen wir uns doch bitte vorläufig auf "nicht entscheidbar", weil das von keinem bestritten wird, weil es wohl das "semi" offen lässt, und weil es wichtig ist... das halteproblem sollte auch erwähnt werden, weil es auch gleich einleuchtende beispiele liefert... --Heimschützenverein 23:13, 23. Jun. 2008 (CEST)Beantworten

Hier gibt's noch was, was sich speziell mit dem Thema Pointer und Entscheidbarkeit beschäftigt. Auch dort ist von Unentscheidbarkeit die Rede.

Das Halteproblem sollte IMHO in unserem Artikel nicht erwähnt werden, solange wir keinen engeren Zusammenhang belegen können.

--Eike 12:16, 24. Jun. 2008 (CEST)Beantworten

oh schreck: mir is grad aufgefallen, dass der artikel gar nicht mit quellen belegt ist... muss er jetzt gelöscht werden? oder reicht da doch mein wort allein...? :) --Heimschützenverein 21:42, 23. Jun. 2008 (CEST)Beantworten

antwort an mich selbst: nope, semi-entscheidbar wäre, wenn die frage, ob kein speicherleck entsteht, bei fehlendem speicherleck stets entscheidbar wäre... :-) also können wir es so lassen, wie es jetzt ist... --Heimschützenzentrum (?) 12:55, 2. Okt. 2012 (CEST)Beantworten

Wieso ist der Abschnitt vorhanden wenn er keine Nachweise enthält? --79.238.214.249 03:40, 2. Okt. 2012 (CEST)Beantworten

mach ihn doch selbst weg, wenns dich stört... WP:SM... --Heimschützenzentrum (?) 07:52, 2. Okt. 2012 (CEST)Beantworten

Bei diesem WP:WAR-Edit stört mich, dass eigentlich das Pseudo-Code Bsp und das Java Bsp voll ausreichen... --Heimschützenzentrum (?) 14:07, 19. Jun. 2014 (CEST)Beantworten

Das Zurücksetzen einer unbegründeten Löschung ist kein WAR. Es ist eher fraglich, warum du so etwas sichtest?

Die beiden Beispiele in C und C++ verdeutlichen anschaulich die Problematik mit malloc/free bzw. new/delete/delete[], die es in ebendiesen Sprachen gibt.

Allerdings könnte man die Beispiele gut auf etwa ein Drittel ihrer Länge kürzen.--Plankton314 (Diskussion) 14:27, 19. Jun. 2014 (CEST)Beantworten

das habe ich gesichtet, weil der Abschnitt gegen WP:WWNI/9 verstößt... wir sollen hier kein Lehrbuch für C++ schreiben... die sind bei Wikibooks... --Heimschützenzentrum (?) 17:25, 19. Jun. 2014 (CEST)Beantworten

Ich habe beide Beispiele jetzt auf wenige Zeilen gekürzt. Ist dir das genug?

Im Zweifelsfall kann ich auch damit leben, es rauszuschmeißen. Dann aber bitte gleich mit dem grotesken "Beispiel für Personen ohne Programmierkenntnisse".--Plankton314 (Diskussion) 18:01, 19. Jun. 2014 (CEST)Beantworten

ich hätte den Artikel in jeder Version der letzten Tage gesichtet... also auch in der jetzigen... hauptsache das Unwort „Determinismus“ taucht nich auf, sonst bin ich wech... :-) --Heimschützenzentrum (?) 18:14, 19. Jun. 2014 (CEST)Beantworten

Determinismus! ... oder determiniert? Hast du es inzwischen mal nachgelesen?--Plankton314 (Diskussion) 19:33, 19. Jun. 2014 (CEST)Beantworten

*nerv* :-) sowas brauch ich eigentlich nich nachzulesen... ich halte den Begriff hier in der WP nicht für wohldefiniert, denn: die Eingabe sollte eben so ordentlich definiert sein, dass die Eingabe zusammen mit dem Algorithmus die Ausgabe eindeutig definiert (d. h. dass ein Algorithmus, der echte Zufallszahlen verwendet, diese Zufallszahlen als Eingabe bekommt... und so ist es in der Praxis ja auch...)... in der theoretischen Informatik ist es anders, aber das hat ja nun mal nix mit deinem Determinismus-Begriff zu tun... --Heimschützenzentrum (?) 20:04, 19. Jun. 2014 (CEST)Beantworten

Wahrscheinlich werde ich diese Frage innerhalb kürzester Zeit bereuen, aber...: Was willst du sagen?--Plankton314 (Diskussion) 20:23, 19. Jun. 2014 (CEST)Beantworten

steht doch da... der Artikel in der WP zum Det. ist Unfug... steht auch dort wenigstens schon in der disk... aber auf mich hört ja keiner... --Heimschützenzentrum (?) 20:38, 19. Jun. 2014 (CEST)Beantworten

Sag, hatten wir das Thema nicht irgendwo schon mal?--Plankton314 (Diskussion) 20:48, 19. Jun. 2014 (CEST)Beantworten

liest du nich was ich schreib? ich hab doch sogar schon geschrieben, wo wir es schon haben... also stellst du die Frage zu meiner bereits gegebenen Antwort oder was? --Heimschützenzentrum (?) 21:04, 19. Jun. 2014 (CEST)Beantworten

Um was geht es jetzt hier?--Plankton314 (Diskussion) 21:07, 19. Jun. 2014 (CEST)Beantworten

es geht darum, dass du zum wiederholten Male noch mehr Unsinn in einen Artikel einbaust und dann merkwürdig mit windigen Studien herumargumentierst und komische Fragen fragst und... --Heimschützenzentrum (?) 21:32, 19. Jun. 2014 (CEST)Beantworten

Was für Studien? Und was möchtest du denn anders haben?--Plankton314 (Diskussion) 21:38, 19. Jun. 2014 (CEST)Beantworten

Habt ihr überhaupt überrissen, warum ich das C++-Beispiel vollständig herausgenommen habe? Falls nein vielleicht nochmal meinen Kommentar (194.118.51.150 04:03, 13. Jun. 2014 (CEST)) unter "Beispiel in C++" lesen ... 212.95.7.179 07:57, 1. Aug. 2014 (CEST)Beantworten

Wie gesagt, das C-Beispiel genügt völlig.--Plankton314 (Diskussion) 14:52, 2. Aug. 2014 (CEST)Beantworten

Dieses Beispiel halte ich für ziemlich verkorkst und auch die Erläuterung potentieller Konsequenzen (im Lift steckenbleiben usw.).

Wie wäre es mit folgendem intuitiv greifbaren Beispiel:

Ein Urlauber reserviert sich eine Strandliege, indem er ein Handtuch darauf legt (Allokation).
Nach dem Schwimmen kehrt er ins Hotel zurück, vergisst aber das Handtuch auf der Liege (Speicherleck).

Die Liege kann nun von niemand anderem mehr belegt werden und kann aber auch nicht freigegeben werden, da der Urlauber den Ort seines Handtuchs vergessen hat.

--Plankton314 (Diskussion) 14:54, 19. Jun. 2014 (CEST)Beantworten

das mit der Liege ist verkorkst, weil der Urlauber anders als n Fahrstuhl-Puter-Programm nach n paar Caipis sich vllt wieder an sein kuscheliges Handtuch erinnert und es wieder abholt... die trinken nämlich nich... --Heimschützenzentrum (?) 17:25, 19. Jun. 2014 (CEST)Beantworten

Oder aber das Handtuch verschwindet durch eine Quantenverschränkung plötzlich. Ein ebenso plausibles Argument.

Es sollte einfach gelöscht werden. Solche Analogien (dazu noch in Pseudocode) haben wohl noch keinem wirklich weiter geholfen.--Plankton314 (Diskussion) 18:01, 19. Jun. 2014 (CEST)Beantworten

1. pseudocode ist didaktisch klug... 2. das Fahrstuhl-Bsp ist anders als das mit der Liege hinreichend praxisnah... --Heimschützenzentrum (?) 18:10, 19. Jun. 2014 (CEST)Beantworten

Es gab dazu mal Versuche an FHs, die zeigen konnten, dass ein Algorithmus in Pseudocode schwerer bis überhaupt nicht verstanden wurde, als in einer Hochsprache wie C, Java oder sogar BASIC.

Homer, so leid es mir tut, aber es zeigt sich nur wieder einmal, wie sinnlos es ist, mit dir zu diskutieren. Bitte tu uns allen den Gefallen und diskutiere nicht um des bloßen Diskutierens Willen. Wenn du wirklich was zu einem Artikel beizutragen hast, mach es (egal, ob auf der Disku oder direkt im Artikel). Aber dieses ewige Zerlabern von allem und jedem ist nicht zielführend und bindet nur unproduktiv Zeit.--Plankton314 (Diskussion) 19:32, 19. Jun. 2014 (CEST)Beantworten

es gab mal... an gleich mehreren Fachhochschulen... so so... und die ganzen Professoren an den Universitäten hätten mal auch lieber Versuche machen sollen? das ist doch nich dein Ernst... der Rest dann wohl auch nich... --Heimschützenzentrum (?) 20:04, 19. Jun. 2014 (CEST)Beantworten

Ja, sorry, ich hab es nur irgendwann mal kurz gelesen.^{[Belege fehlen]} Aber das Pseudocode didaktisch sinnvoll wäre, ist bestenfalls umstritten.--Plankton314 (Diskussion) 20:23, 19. Jun. 2014 (CEST)Beantworten

ach, so ist das also... dachte ich mir schon... für eine Umstrittenheit sehe ich weiterhin gar keinen vernünftigen Grund... des Weiteren schweift das Beispiel eben nicht an Urlaubsstrände mit Liegen ab, sondern bleibt bei einem Praxis-nahen, anschaulichen Beispiel, ohne sich mit irgendwelchen unausgegorenen Konzepten (z. B.: OO/GC) herumzuplagen... --Heimschützenzentrum (?) 20:38, 19. Jun. 2014 (CEST)Beantworten

Sagen wir es mal so: Weder das Fahrstuhl- noch das C++-Beispiel helfen beim Verständnis über das hinaus, was nicht schon ohnehin im Text steht.--Plankton314 (Diskussion) 20:48, 19. Jun. 2014 (CEST)Beantworten

ja... aber: so soll es ja auch sein (der Leser soll eben ein konkretes Speicherleck sehen können...)... es sollte bloß eben viel knapper sein (und nich 3× free() vergessen/verunmöglicht...)... --Heimschützenzentrum (?) 21:04, 19. Jun. 2014 (CEST)Beantworten

Gut, dann disqualifiziert das eindeutig dieses komische Fahrstuhl-Bsp. Das übrigens aus de EN.WP hier rübergeschwappt ist.--Plankton314 (Diskussion) 21:07, 19. Jun. 2014 (CEST)Beantworten

falsch und tschüß! :-) --Heimschützenzentrum (?) 21:32, 19. Jun. 2014 (CEST)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

– GiftBot (Diskussion) 07:56, 30. Nov. 2015 (CET)Beantworten