Blödsinn. Wenn malloc scheitert, kann das auch nur bedeuten, dass ein bestimmter Zweig nicht ausgeführt werden kann.
Du vergisst, dass der gesamte Prozess nur diese eine Speicherverwaltung hat. Es können dann auch andere Zweige nicht mehr funktionieren, die den Heap benutzen. Weisst du genau, dass keine API-Funktion Speicher alloziert, die in anderen Zweigen benutzt wird?
Und du vergisst, dass das Fehlschlagen von malloc(100000000) nicht bedeuten muss, dass andere Funktionen nichts mehr vom Heap abkriegen.
_________________ Wie viele atheistische Babys hat man schon aus Versehen - oder gar mit Absicht! - getauft?
Du vergisst, dass der gesamte Prozess nur diese eine Speicherverwaltung hat. Es können dann auch andere Zweige nicht mehr funktionieren, die den Heap benutzen. Weisst du genau, dass keine API-Funktion Speicher alloziert, die in anderen Zweigen benutzt wird?
Versuch's mal mit was anderem, als Schwachsinnigkeit zu demonstrieren.
Ein Zweig kriegt keinen Speicher mehr, heißt aber nicht zwangsläufig, daß die Kiste mitm Memleak abkackt.
Der gleiche Parser (sh. letzte Beiträge) läuft auf Kisten mit 32kB Heap genauso wie mit 256 MB Heap, nur daß der PC nicht zwischendurch abräumen muß, der Controller das bei gleicher Filegröße ein paar hundert mal machen muß. Er ist einfach nur skalierbar programmiert.
Und du vergisst, dass das Fehlschlagen von malloc(100000000) nicht bedeuten muss, dass andere Funktionen nichts mehr vom Heap abkriegen.
Ich dachte mehr an einen Zustand der Fragmentierung, wobei noch nicht mal mehr 0x1000 Bytes möglich sind. Aber auch wenn "nur" Deine 100000000-Bytes Allokation nicht funktioniert, brauchst Du eine Ausweichmöglichkeit. Tatsache ist: Dein Programm kann sich, wenn Du malloc verwendest, zu einem unvorhersehbaren Zeitpunkt anders verhalten als sonst.
zu einem unvorhersehbaren Zeitpunkt anders verhalten als sonst.
Das ist bei C immer mal drin
Eigentlich verwende ich malloc() recht selten, meist, wenn ich eine Datei komplett
lesen will und vorher nicht weiß wie groß die sein könnte (dann: Größe ermitteln,
malloc und laden). Ansonsten aus Laufzeitgründen meist statische Arrays (dramatisch
schneller als jeden Record mit malloc anzulegen). Sollte da etwas schiefgehen, kann
ich die Daten auch nicht weiterverarbeiten -> Abbruch.
Bastele ich ein Programm, das auf Eingaben reagiert (zB Webserver) sieht die
Geschichte völlig anders aus. Dort laufe ich aber mit der Zeit in einen sauber
zerlegten und fragmentierten Heap der die Sache auch nicht besser macht.
Bei einem netten kleinen uC (etwa PIC) kann ich mir malloc eh schenken ...
Ich dachte mehr an einen Zustand der Fragmentierung, wobei noch nicht mal mehr 0x1000 Bytes möglich sind.
Das ist aber nur einer der möglichen Fälle. Nur anhand dessen kann man keine allgemeingültige Aussage darüber treffen, ob nach Fehlschlagen von malloc ein Weiterführen des Programms sinnvoll sein könnte.
collam schrieb:
Aber auch wenn "nur" Deine 100000000-Bytes Allokation nicht funktioniert, brauchst Du eine Ausweichmöglichkeit.
Was meinst du mit Ausweichmöglichkeit? Wenn ich einen bestimmten Programmteil nicht ausführen kann, weil die dafür nötige, vielleicht sehr große Allokation nicht möglich ist, informiere ich den Benutzer und starte diesen Programmteil nicht. Das wäre dann irgendwie das ausweichen, ja? Wenn dann natürlich durch kaum mehr verfügbaren/stark fragmentierten Speicher wirklich keine Allokation mehr klappt, wird der Benutzer halt einfach kaum noch Funktionen ausführen können und sich ständig über "out of memory" Meldungen ärgern. Dann ist natürlich ein Beenden der SW nötig. Und dieser Fall bedeutet dann auch, dass die SW genausogut hätte abschmieren können (in beiden Fällen kann der Benutzer mit der Software nix mehr anfangen). Ich finde halt nur, dass man den erstgenannten Fall auch bedenken und in der SW berücksichtigen sollte, falls das dem Benutzer was bringen kann.
_________________ Wie viele atheistische Babys hat man schon aus Versehen - oder gar mit Absicht! - getauft?
Sieh es aus Benutzersicht: Macht es überhaupt Sinn, das Programm weiterlaufen
zu lassen (falls es technisch möglich ist) ?
Dann: Wieso kommt es eigentlich zu der übergroßen Speicheranforderung ? Ist da
vielleicht vorher irgendetwas nicht auf Plausibilität geprüft worden ? Macht der
Benutzer Unfug (wie zB 100000 Fotos im RAW-Format laden) ?
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Sie können Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum antworten. Sie können Ihre Beiträge in diesem Forum nicht bearbeiten. Sie können Ihre Beiträge in diesem Forum nicht löschen. Sie können an Umfragen in diesem Forum nicht mitmachen.
c++.de ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums
für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de
Werbekostenerstattung verdient werden kann.
Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info, www.c-sar.de, www.c-plusplus.net und www.baeckmann.de
enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt
(vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in
privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden.
Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere
übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.
Twitter
Facebook
