C/C++ Forum :: "Komfort" bei malloc

plizzz Mitglied 11:10:27 08.03.2010 Titel:

Hallo ihr,
es wird einem ja stets mit auf den Weg gegeben, nach jeder Benutzung von malloc zu prüfen, ob man überhaupt Speicher reserviert bekommen hat, bevor man irgendwie weitermacht. Nun hätte ich es gerne so, dass sich das Programm mit einer Fehlermeldung beendet, wenn malloc fehlschlägt. Bis jetzt habe ich das immer so gemacht, dass ich bei einem Fehlschlag von malloc NULL oder 0 als return-Wert der jeweiligen Funktion zurückgegeben habe, die Funktion darüber hat das dann auch gemacht und dann wieder [...] und irgendwann ist man bei der main und kann die mit return 0 beenden. Bloß wird diese Methode sehr nervig, je längere Funktionsketten man hat, außerdem gibt es Probleme mit int/double Funktionen, die auch von sich aus alle möglichen Werte zurückgeben können (dann kann man keinen speziellen auswählen, der jetzt einen malloc-Fehlschlag darstellt). Deshalb die Frage:

Gibt es eine Möglichkeit, aus einer Funktion heraus nicht nur die aktuelle Funktion, sondern das komplette Programm zu beenden? Wenn nein, wie kann man obiges Problem mit malloc ansonsten vernünftig lösen?

MfG plizzz

Unregistrierter

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	1 2 3 4 5 6 7 8 9 10 11 12	void malloc_x (size_t length) { void* m = malloc (length); if (m == 0) { fprintf (stderr, "DAMN!!!"); exit (1); } return* m; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	void malloc_x (size_t length) { void* m = malloc (length); if (m == 0) { fprintf (stderr, "DAMN!!!"); exit (1); } return* m; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	void malloc_x (size_t length) { void* m = malloc (length); if (m == 0) { fprintf (stderr, "DAMN!!!"); exit (1); } return* m; }

_matze Mitglied 11:23:15 08.03.2010 Titel:

Sieh dir vielleicht mal Exceptions an...

Unregistrierter

_matze schrieb:

Sieh dir vielleicht mal Exceptions an...

Wir sind hir nicht bei Java du Spacken!

_matze Mitglied 11:42:51 08.03.2010 Titel:

Gut, das ist das C-Forum, hab ich nicht bedacht (deine niveaulosen Beleidigungen kannst du dir natürlich trotzdem sparen). Für den Fall, dass der MS-Compiler verwendet wird, gibt es allerdings immerhin die Exception-Erweiterung für C (__try, __except, __finally).

Unregistrierter

_matze schrieb:

Gut, das ist das C-Forum, hab ich nicht bedacht (deine niveaulosen Beleidigungen kannst du dir natürlich trotzdem sparen). Für den Fall, dass der MS-Compiler verwendet wird, gibt es allerdings immerhin die Exception-Erweiterung für C (__try, __except, __finally).

__try, __except und __finally haben haben rein garnichts mit der Frage von plizz zu tun. Warum schreibst du hier wenn du keine Ahnung hast? :mad:

plizzz Mitglied 12:39:32 08.03.2010 Titel:

Ganz ruhig. Mir ist zwar durchaus bewusst, dass die Frage nach der richtigen malloc-Lösung enormes Konfliktpotenzial in sich trägt, ich wollte aber dennoch keinen Privatkrieg damit auslösen.

Zum obigen Code: Im Endeffekt läuft es da wohl auf die Benutzung von exit() hinaus, was das Programm scheinbar schließt. Das riecht allerdings nach einer Lösung, bei der das halbe Forum hier wild schreiend die Fackel anzünden würde, da es wohl irgendwelche Nebenwirkungen gibt a la "vorher allokierter Speicher wird nicht freigegeben". Oder ist diese exit-Variante eher unproblematisch und man kann sie guten Gewissens verwenden?

Unregistrierter

Du kannst mit ruhiger Gewissheit davon ausgehen, dass diese Vorgehensweise Grütze ist.
MfG,
B.B.

Unregistrierter

plizzz schrieb:

Oder ist diese exit-Variante eher unproblematisch und man kann sie guten Gewissens verwenden?

Windows gibt allen Speicher frei wenn das Programm beendet wird.

_matze Mitglied 13:11:10 08.03.2010 Titel:

collam schrieb:

plizzz schrieb:

Oder ist diese exit-Variante eher unproblematisch und man kann sie guten Gewissens verwenden?

Windows gibt allen Speicher frei wenn das Programm beendet wird.

Von Windows war hier übrigens nie die Rede. Willst du dich wirklich darauf verlassen, dass jedes in Frage kommende Betriebssystem unter allen Umständen alle Speicherleichen eines beendeten Prozesses freimacht? Das ist einfach schlechter Stil. Wer Speicher anfordert, sollte diesen auch wieder freigeben. Zumal eine Rückgabe NULL von malloc nicht unbedingt bedeuten muss, dass man sein Programm komplett beenden will (auch, wenn plizzz es in diesem Fall so machen will; vielleicht entscheidet er später auch mal anders)... :rolleyes:

namespace invader Mitglied 13:19:30 08.03.2010 Titel:

collam schrieb:

void *m = malloc (length);
if (m == 0)

Besser ist stattdessen if (!m && length), da malloc ja NULL zurückgeben kann, wenn man ein Array der Länge 0 haben will.

_matze schrieb:

Gut, das ist das C-Forum, hab ich nicht bedacht (deine niveaulosen Beleidigungen kannst du dir natürlich trotzdem sparen). Für den Fall, dass der MS-Compiler verwendet wird, gibt es allerdings immerhin die Exception-Erweiterung für C (__try, __except, __finally).

Man kann sich auch mit longjmp und Makros Exceptions basteln. Natürlich muss man dann auch das ganze Programm entsprechend umschreiben, also mit Verwaltung eines Cleanup-Stacks usw. Ich würde damit aber nicht anfangen, allein um malloc-Fehlschläge abzufangen, die in der Praxis vermutlich ohnehin niemals auftreten.

plizzz schrieb:

da es wohl irgendwelche Nebenwirkungen gibt a la "vorher allokierter Speicher wird nicht freigegeben".

Der Standard garantiert nicht, dass es solche Nebenwirkungen nicht gibt, aber in der Regel kann man trotzdem davon ausgehen, dass es keine Probleme gibt.

Es gibt sinnvollere Dinge, die man machen kann, als sein Programm von Malloc-Fehlerbehandlung aufzublähen.

_matze Mitglied 13:28:04 08.03.2010 Titel:

namespace invader schrieb:

allein um malloc-Fehlschläge abzufangen, die in der Praxis vermutlich ohnehin niemals auftreten.

Das kommt halt auf das Programm an. Bei uns gibt es solche Fälle (wir hantieren aber auch mit sehr großen Speicherblöcken). Das kleine Prgrämmchen, das in Summe 20 MB braucht, wird malloc-Fehler wohl kaum zu Gesicht bekommen.

Unregistrierter

namespace invader schrieb:

Besser ist stattdessen if (!m && length), da malloc ja NULL zurückgeben kann, wenn man ein Array der Länge 0 haben will.

Was man auch als Fehler ansehen könnte.

namespace invader Mitglied 13:54:08 08.03.2010 Titel:

_matze schrieb:

Das kommt halt auf das Programm an. Bei uns gibt es solche Fälle (wir hantieren aber auch mit sehr großen Speicherblöcken). Das kleine Prgrämmchen, das in Summe 20 MB braucht, wird malloc-Fehler wohl kaum zu Gesicht bekommen.

Ok, kommt eben darauf an: Wenn man sehr große Blöcke reservieren will, deren Größe vielleicht auch von den Eingabedaten abhängt, ist es sicher sinnvoll, vernünftig auf den Fehler zu reagieren.

Wenn es nur um ein paar 20-Byte-Objekte geht, und man unabhängig von den Eingabedaten sicherstellen kann, wie viele es höchstens werden, ist es durchaus legitim, davon auszugehen, dass ein malloc-Fehlschlag entweder ein Problem beim Betriebssystem ist oder ein Bug im eigenen Programm ist. Und dafür eine komplizierte Fehlerbehandlung zu schreiben halte ich für übertrieben. Letztendlich ist das verglichbar mit einem Stacküberlauf, bei dem ja auch das Programm einfach beendet wird, ohne dass noch irgendwas freigegeben wird.

namespace invader Mitglied 14:00:15 08.03.2010 Titel:

collam schrieb:

Was man auch als Fehler ansehen könnte.

Nicht unbedingt, manchmal läuft es eben darauf hinaus, dass man von irgendetwas nur 0 Elemente hat, und NULL ist ein problemlos verwendbarer Zeiger auf ein Array der Länge 0, man kann dann in einer for-Schleife alle 0 Elemente durchlaufen usw., und das Array später auch mit realloc vergrößern.

_matze Mitglied 14:12:28 08.03.2010 Titel:

namespace invader schrieb:

Ok, kommt eben darauf an: Wenn man sehr große Blöcke reservieren will, deren Größe vielleicht auch von den Eingabedaten abhängt, ist es sicher sinnvoll, vernünftig auf den Fehler zu reagieren.

Wenn es nur um ein paar 20-Byte-Objekte geht, und man unabhängig von den Eingabedaten sicherstellen kann, wie viele es höchstens werden, ist es durchaus legitim, davon auszugehen, dass ein malloc-Fehlschlag entweder ein Problem beim Betriebssystem ist oder ein Bug im eigenen Programm ist. Und dafür eine komplizierte Fehlerbehandlung zu schreiben halte ich für übertrieben. Letztendlich ist das verglichbar mit einem Stacküberlauf, bei dem ja auch das Programm einfach beendet wird, ohne dass noch irgendwas freigegeben wird.

Full Ack, finde ich ok so (auch, wenn bei uns sogar für kleine 50-Byte-Allokationen die malloc-Rückgabe geprüft wird...).

plizzz Mitglied 14:15:50 08.03.2010 Titel:

Ich habe es jetzt doch so gelöst, dass ich bei fehlgeschlagenem malloc NULL oder 0 bis in die main zurückgebe und dann halt eben da beende. Mir ist ein fehlgeschlagener malloc zwar auch noch nie untergekommen und ich weiß auch nicht, ob das je passieren wird, allerdings ist bei mir der zu allokierende Speicher eben von den Eingabedaten abhängig und da mache ich dann lieber so eine Abfrage rein. Aber eine "einfache", unumstrittene Lösung scheint es da ja gar nicht so wirklich zu geben.

Unregistrierter

namespace invader schrieb:

collam schrieb:

Was man auch als Fehler ansehen könnte.

Nicht unbedingt, manchmal läuft es eben darauf hinaus, dass man von irgendetwas nur 0 Elemente hat, und NULL ist ein problemlos verwendbarer Zeiger auf ein Array der Länge 0, man kann dann in einer for-Schleife alle 0 Elemente durchlaufen usw., und das Array später auch mit realloc vergrößern.

Der Rückgabewert von malloc ist unbrauchbar, wenn ich malloc mit 0 aufrufe. Warum sollte man es dann tun?

Unregistrierter

plizzz schrieb:

Ich habe es jetzt doch so gelöst, dass ich bei fehlgeschlagenem malloc NULL oder 0 bis in die main zurückgebe und dann halt eben da beende.

Wenn du die Null nicht als Fehlermeldung verwenden kannst, könntest du auch einen weiteren Paramter einführen, einen Zeiger auf eine Variable, in der die Fehlermeldung abgelegt wird. Oder eine globale Variable (globale Variablen sind aber nicht immer eine gute Idee).

plizzz schrieb:

Mir ist ein fehlgeschlagener malloc zwar auch noch nie untergekommen und ich weiß auch nicht, ob das je passieren wird, allerdings ist bei mir der zu allokierende Speicher eben von den Eingabedaten abhängig und da mache ich dann lieber so eine Abfrage rein.

Du kannst einfach nicht wissen, welche Umstände du vorfinden wirst. Vielleicht ist die Ziel-CPU gerade mit der Suche nach einem 17er-Sudoku beschäftigt und hat dafür gerade den ganzen Speicher in Beschlag genommen. Soll schon passiert sein.

plizzz schrieb:

Aber eine "einfache", unumstrittene Lösung scheint es da ja gar nicht so wirklich zu geben.

Zumindest hat sie noch keiner entdeckt. Davon auszugehen, dass malloc() schon nicht NULL liefern wird, ist jedenfalls keine. Wenn du dich andererseits darauf verlassen willst, dass das Betriebssystem irgendwelche Nicht-Standard-Magie macht, bist du im falschen Forum.

Vielleicht kommt ein Garbage Collector deiner Vorstellung von Komfort entgegen:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Vielleicht ist C auch einfach nicht das passende Werkzeug für deine Aufgabe, üblicherweise ist man in C froh über die manuelle Speicherverwaltung.

plizzz Mitglied 16:01:39 08.03.2010 Titel:

Nein nein, da verstehst du mich falsch. Ich möchte im Grunde nichts verändern an meiner Speicherverwaltung. Ich wollte lediglich wissen, ob es nicht evtl. eine übersichtlichere Methode gibt, die ganzen malloc-Abfragen zu realisieren, anstatt irgendwelche Rückgabewerte durch die Funktionen durchzureichen. Da es da scheinbar keine eierlegende Wollmilchsau in dieser Angelegenheit gibt, bleibe ich bei dieser Methode und versuche halt, diese sinnvoll einzubinden. Bloß will man es ja doch schon besser machen, wenn es denn besser geht.

namespace invader Mitglied 16:03:59 08.03.2010 Titel:

collam schrieb:

Der Rückgabewert von malloc ist unbrauchbar, wenn ich malloc mit 0 aufrufe. Warum sollte man es dann tun?

Weil es manchmal eleganter ist, als den Fall einer Größe von 0 gesondert behandeln zu müssen. Manchmal hat man eben Datenpakete oder sonstwas der Länge 0, die aber trotzdem nicht komplett unterschlagen werden dürfen.

Unregistrierter

plizzz schrieb:

Ich habe es jetzt doch so gelöst, dass ich bei fehlgeschlagenem malloc NULL oder 0 bis in die main zurückgebe und dann halt eben da beende.

Genau so ist es fein.

plizzz schrieb:

Aber eine "einfache", unumstrittene Lösung scheint es da ja gar nicht so wirklich zu geben.

Doch gibt es. Z.B. aus der main heraus die Funktionen für die Speicherfreigabe aufrufen und mit 'return irgendwas' beenden.

Unregistrierter

namespace invader schrieb:

Manchmal hat man eben Datenpakete oder sonstwas der Länge 0, die aber trotzdem nicht komplett unterschlagen werden dürfen.

Das ist doch Unsinn! Alles was die Länge 0 hat kann unterschlagen werden. :rolleyes:

Unregistrierter

namespace invader schrieb:

collam schrieb:

void *m = malloc (length);
if (m == 0)

Besser ist stattdessen if (!m && length), da malloc ja NULL zurückgeben kann, wenn man ein Array der Länge 0 haben will.

schweres thema, was sagt der standard dazu?

7.20.3 Memory management functions schrieb:

If the space cannot be allocated, a null pointer is returned. If the size of the space requested is zero, the behavior is implementationdefined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.

so wie ich das verstehe, kann das jeder so machen wie er will! hat mich also nicht weiter gebracht...
schauen wir doch mal wie das in der glibc gemacht wurde;)

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	1 2 3 4 5 6 7 8 9 10	/* Allocate an N-byte block of memory from the heap. If N is zero, allocate a 1-byte block. / void* * rpl_malloc (size_t n) { if (n == 0) n = 1; return malloc (n); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	/* Allocate an N-byte block of memory from the heap. If N is zero, allocate a 1-byte block. / void* * rpl_malloc (size_t n) { if (n == 0) n = 1; return malloc (n); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	/* Allocate an N-byte block of memory from the heap. If N is zero, allocate a 1-byte block. / void* * rpl_malloc (size_t n) { if (n == 0) n = 1; return malloc (n); }

huch was ist denn das, ein malloc(0) reserviert auch ein char :warning:

macht ja auch sinn, denn das ist mehr oder weniger die einzige möglichkeit das relativ sauber über die bühne zu bringen.

noch ein kurzer test

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	1 2 3 4 5 6 7 8 9 10 11 12 13	#include <stdio.h> #include <stdlib.h> int main() { void x = malloc(0); if(x==NULL) puts("error"); else* puts("no error"); return 0; } ausgabe: "no error"

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	#include <stdio.h> #include <stdlib.h> int main() { void x = malloc(0); if(x==NULL) puts("error"); else* puts("no error"); return 0; } ausgabe: "no error"

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	#include <stdio.h> #include <stdlib.h> int main() { void x = malloc(0); if(x==NULL) puts("error"); else* puts("no error"); return 0; } ausgabe: "no error"

lg lolo

_matze Mitglied 17:48:06 08.03.2010 Titel:

Über die Stelle im Standard gab es schon mal eine Diskussion. Und auch damals habe ich mich gefragt, was man mit dieser Variante (Adresse für Puffer der Länge 0 zurückliefern) eigentlich bezwecken will... :confused:

Unregistrierter

_matze schrieb:

Über die Stelle im Standard gab es schon mal eine Diskussion. Und auch damals habe ich mich gefragt, was man mit dieser Variante (Adresse für Puffer der Länge 0 zurückliefern) eigentlich bezwecken will... :confused:

NULL ist doch die einzige möglichkeit einen fehler aus der function raus zu bringen, da ja jeder andere wert einen potentiellen speicher bereich darstellt. und ein aufruf mit 0 stellt ja streng genommen keinen fehler dar.
so wie ich das sehe ist der vorschlag von namespace invader "(!m && length)" nicht schlecht aber wenn man die glibc verwendet leider überflüssig...

im letzten satz hab ich ja ganz vergessen das wir ja hier im ansi c forum sind

pointercrash() Mitglied 21:04:16 08.03.2010 Titel:

plizzz schrieb:

Ich wollte lediglich wissen, ob es nicht evtl. eine übersichtlichere Methode gibt, die ganzen malloc-Abfragen zu realisieren, anstatt irgendwelche Rückgabewerte durch die Funktionen durchzureichen. Da es da scheinbar keine eierlegende Wollmilchsau in dieser Angelegenheit gibt ...

Du hast schon recht, die probate Methode ist das Durchreichen von Errorleveln, weil:
- so goto- Zeugs ist super für lokale Cleanups, exit und anderes Brutalo- Zeugs hilft wenig bei der Fehlersuche.
- Du kannst je nach call depth differenzierte Fehlerbehandlungsstrategien ansetzen.

Eigentlich ist es wichtiger, mal ein einheitliches Schema aufzusetzen. Ich bin mal so frech und sage, wenn alles gutgegangen ist, muß man dem nichts hinzufügen und das gibt den Rückgabewert 0. Dann kann ich dem Nicht- Null- Fall zigtausend Infos mitgeben, was gerade gekrackst hat, muß ja nicht nur malloc() sein.

Man kann dadurch an jedem Rückgabelevel entscheiden, was man tun muß und ist nur selten auf Überlegungen angewiesen, was das OS denn jetzt macht.

mazal Mitglied 21:14:18 08.03.2010 Titel:

http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html

Unregistrierter

plizzz schrieb:

Ich wollte lediglich wissen, ob es nicht evtl. eine übersichtlichere Methode gibt, die ganzen malloc-Abfragen zu realisieren, anstatt irgendwelche Rückgabewerte durch die Funktionen durchzureichen.

Dynamische Sprünge nach aussen gibt es, sind schon erwähnt worden. Ist vielleicht in manchen Fällen besser, als Kaskaden von Wert-Übergaben einzurichten, wenn man in der Mitte gar nichts mit den Werten anstellen will.

_matze schrieb:

Über die Stelle im Standard gab es schon mal eine Diskussion. Und auch damals habe ich mich gefragt, was man mit dieser Variante (Adresse für Puffer der Länge 0 zurückliefern) eigentlich bezwecken will... :confused:

Kann mich errinnern. Der Compiler darf dafür sorgen, dass eine Verwaltungsstruktur auf dem Heap erstellt wird, auch wenn der zugehörige Puffer die Länge 0 hat. Der einzige Sinn, den ich bis jetzt dahinter gefunden habe, war, dass damit die Tradition eingehalten wird, möglichst wenige Vorschriften zu machen. Immerhin könnte man sich vielleicht ein paar Prozessor-Takte sparen, wenn man nicht immer prüfen muss, ob der malloc-Parameter 0 ist.

Z Mitglied 22:16:30 08.03.2010 Titel:

noobLolo schrieb:

NULL ist doch die einzige möglichkeit einen fehler aus der function raus zu bringen, da ja jeder andere wert einen potentiellen speicher bereich darstellt. und ein aufruf mit 0 stellt ja streng genommen keinen fehler dar.

Nein, aber er ist sinnlos, wie schon auf der ersten Seite erwähnt wurde.
Ich habe zum Spass mal das gemacht:

C/C++ Code:
while(1) void *z = malloc(0);

C/C++ Code:
while(1) void *z = malloc(0);

C/C++ Code:
while(1) void *z = malloc(0);

Bei mir läuft der Speicher ganz langsam voll, VS 2005, ca 1.6 GB nach 5 Minuten.
Da offensichtlich free() bei malloc(0) nötig ist, würde ich lieber sicherstellen, dass im Programm kein malloc(0) vorkommt.

namespace invader Mitglied 22:44:20 08.03.2010 Titel:

Z schrieb:

Bei mir läuft der Speicher ganz langsam voll, VS 2005, ca 1.6 GB nach 5 Minuten.

Wenn malloc(0) nicht NULL zurückgibt, muss man das natürlich wieder freigeben. Wenn malloc(0) NULL zurückgibt, schadet free() aber auch nicht. Am besten ruft man also einfach zu jedem malloc free auf (wäre käme denn auch auf die Idee, das nicht zu tun?)

Wie gesagt kann malloc(0) vorkommen, wenn man sich einfach die Sonderbehandlung des Falls einer Größe von 0 spart.

Zum Beispiel: Man ließt irgendwelche Pakete aus einer Datei, wobei vorher jeweils die Paketgröße selber in der Datei steht. D.h. man ließt die Größe, malloct so viel Speicher, füllt ihn mit fread(buffer,size,1,f), und macht dann irgendwas damit, wobei man natürlich nur auf Arrayindizes 0 <= i < size zugreift.

Und wenn dann mal als Größe 0 gelesen wird (was ja vielleicht im Eingabeformat erlaubt ist) und malloc NULL liefert, funktioniert das immer noch völlig problemlos und standardkonform, ohne dass man diesen Fall gesondert behandelt haben muss.

Unregistrierter

Z schrieb:

Da offensichtlich free() bei malloc(0) nötig ist, würde ich lieber sicherstellen, dass im Programm kein malloc(0) vorkommt.

die sache ist, stell dir vor du gibst eine verkettete liste frei, in dieser liste sind per malloc(x) besorgte speicher blöcke abgelegt, die freigabe routine müßte nun immer checken ob auch was zum freigeben da ist, da ja ein free(NULL) auch was ganz schlimmes ist. also ist eigentlich das problem verschoben...

Z Mitglied 22:53:33 08.03.2010 Titel:

namespace invader schrieb:

Wie gesagt kann malloc(0) vorkommen, wenn man sich einfach die Sonderbehandlung des Falls einer Größe von 0 spart.

Das ist wohl Geschmackssache. Ich würde bei Werten aus nicht 100%ig vertrauenswürdiger Quelle immer auf Gültigkeit prüfen:

C/C++ Code:
size_t n = irgendwo_hergeholt(); void a; if (n > 0 && n <= MAX) a = malloc(n); else* a = 0; // oder Fehlerbehandlung

C/C++ Code:
size_t n = irgendwo_hergeholt(); void a; if (n > 0 && n <= MAX) a = malloc(n); else* a = 0; // oder Fehlerbehandlung

C/C++ Code:
size_t n = irgendwo_hergeholt(); void a; if (n > 0 && n <= MAX) a = malloc(n); else* a = 0; // oder Fehlerbehandlung

Unregistrierter

namespace invader schrieb:

Wie gesagt kann malloc(0) vorkommen, wenn man sich einfach die Sonderbehandlung des Falls einer Größe von 0 spart.

Das klingt sinnvoll. Passt auch gut zum Standard, der vorschreibt, dass man den Zeiger von malloc(0) in jedem Fall an free() weitergeben darf, weil free(NULL) nichts tut.

noobLolo schrieb:

da ja ein free(NULL) auch was ganz schlimmes ist

Hättest nicht mehr oft umblättern müssen bis:

TC2 7.20.3.1 schrieb:

The free function causes the space pointed to by ptr to be deallocated, that is, made
available for further allocation. If ptr is a null pointer, no action occurs.

Unregistrierter

noobLolo schrieb:

Z schrieb:

Da offensichtlich free() bei malloc(0) nötig ist, würde ich lieber sicherstellen, dass im Programm kein malloc(0) vorkommt.

die sache ist, stell dir vor du gibst eine verkettete liste frei, in dieser liste sind per malloc(x) besorgte speicher blöcke abgelegt, die freigabe routine müßte nun immer checken ob auch was zum freigeben da ist, da ja ein free(NULL) auch was ganz schlimmes ist. also ist eigentlich das problem verschoben...

habs gerade nochmal getestet, free(0) geht, hab das iwie mit uninitialisierten pointern vertauscht

C/C++ Code:
void *p; free(p);

C/C++ Code:
void *p; free(p);

C/C++ Code:
void *p; free(p);

=> *boom*

lg lolo

Unregistrierter

Z schrieb:

C/C++ Code:
while(1) void *z = malloc(0);

C/C++ Code:
while(1) void *z = malloc(0);

C/C++ Code:
while(1) void *z = malloc(0);

Bei mir läuft der Speicher ganz langsam voll, VS 2005, ca 1.6 GB nach 5 Minuten.

Könnte mir jemand das erklären wieso das so ist?

Das ist irgendwie interessant auch wenn es blödsinnig aussieht.

Unregistrierter

woooooah schrieb:

Z schrieb:

C/C++ Code:
while(1) void *z = malloc(0);

C/C++ Code:
while(1) void *z = malloc(0);

C/C++ Code:
while(1) void *z = malloc(0);

Bei mir läuft der Speicher ganz langsam voll, VS 2005, ca 1.6 GB nach 5 Minuten.

Könnte mir jemand das erklären wieso das so ist?

Das ist irgendwie interessant auch wenn es blödsinnig aussieht.

wieso postest du in einen thread den du nicht gelesen hast? :rolleyes:

Unregistrierter

noobLolo schrieb:

wieso postest du in einen thread den du nicht gelesen hast? :rolleyes:

Ich hab den thread gelesen aber ich verstehe nicht wieso 0 bytes auch eine größe ist. was wird da angefordert?

Unregistrierter

evtl. hast auch ein problem mit deinem englisch :confused:

noobLolo schrieb:

...
schauen wir doch mal wie das in der glibc gemacht wurde;)

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	1 2 3 4 5 6 7 8 9 10	/* Allocate an N-byte block of memory from the heap. If N is zero, allocate a 1-byte block. / void* * rpl_malloc (size_t n) { if (n == 0) n = 1; return malloc (n); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	/* Allocate an N-byte block of memory from the heap. If N is zero, allocate a 1-byte block. / void* * rpl_malloc (size_t n) { if (n == 0) n = 1; return malloc (n); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	/* Allocate an N-byte block of memory from the heap. If N is zero, allocate a 1-byte block. / void* * rpl_malloc (size_t n) { if (n == 0) n = 1; return malloc (n); }

...

Unregistrierter

danke nooblolo

hab es aus dem thread nicht rauslesen können!

Unregistrierter

heyhoi schrieb:

Ich hab den thread gelesen aber ich verstehe nicht wieso 0 bytes auch eine größe ist. was wird da angefordert?

Nichts. Was die Gnu libc tut, kannst du getrost ignorieren, ist ja keine Referenz-Implementation. Den Speicher verbraucht in dem Fall grossteils/ausschliesslich der Overhead.

Scheppertreiber Mitglied 00:23:47 09.03.2010 Titel:

Wird malloc() mit der Länge 0 aufgerufen ist vorher etwas schiefgelaufen.
Der Fall sollte normaerweise nicht auftreten bzw es sollte vorher geprüft
und reagiert werden.

Kann das OS den Speicher nicht bereitstellen ist es so gut wie immer
sinnfrei, das Programm weiterlaufen zu lassen. Wozu auch ?
Also: exit() und raus.

Da der Fall äußerst selten vorkommt (ok, bei mir. Mag bei anderen anders
aussehen) ignoriere ich "Nebeneffekte". Da soll sich das OS drum kümmern.

_matze Mitglied 07:12:48 09.03.2010 Titel:

Scheppertreiber schrieb:

Kann das OS den Speicher nicht bereitstellen ist es so gut wie immer
sinnfrei, das Programm weiterlaufen zu lassen. Wozu auch ?
Also: exit() und raus.

Na weil es vielleicht möglich sein sollte, dass ein bestimmter Programmteil aus irgendwelchen Gründen wie z.B. auch "nicht genug Speicher" nicht ausgeführt werden kann, ohne dass gleich die ganze Software böse abschmiert. Dann lieber die Rückgabe prüfen und ggf. eine Meldung raushauen, damit der User Bescheid weiß, aber nicht gleich den ganzen Prozess abschießen.

Scheppertreiber Mitglied 08:09:04 09.03.2010 Titel:

_matze schrieb:

Na weil es vielleicht möglich sein sollte, dass ein bestimmter Programmteil aus irgendwelchen Gründen wie z.B. auch "nicht genug Speicher" nicht ausgeführt werden kann, ohne dass gleich die ganze Software böse abschmiert. Dann lieber die Rückgabe prüfen und ggf. eine Meldung raushauen, damit der User Bescheid weiß, aber nicht gleich den ganzen Prozess abschießen.

Ok, das hängt von ... ab. In den meisten Fällen hat es ja einen Grund, Speicher
vom OS anzufordern. Klar sind Fälle denk- und konstruierbar wo das Programm auch
ohne weiterlaufen oder sich kontrolliert beenden kann. Nur, bevor ich mir Daten
schieße, lieber abbrechen und nach der Ursache suchen und diese beheben.

Unregistrierter

Scheppertreiber schrieb:

_matze schrieb:

Na weil es vielleicht möglich sein sollte, dass ein bestimmter Programmteil aus irgendwelchen Gründen wie z.B. auch "nicht genug Speicher" nicht ausgeführt werden kann, ohne dass gleich die ganze Software böse abschmiert. Dann lieber die Rückgabe prüfen und ggf. eine Meldung raushauen, damit der User Bescheid weiß, aber nicht gleich den ganzen Prozess abschießen.

Ok, das hängt von ... ab. In den meisten Fällen hat es ja einen Grund, Speicher
vom OS anzufordern. Klar sind Fälle denk- und konstruierbar wo das Programm auch
ohne weiterlaufen oder sich kontrolliert beenden kann. Nur, bevor ich mir Daten
schieße, lieber abbrechen und nach der Ursache suchen und diese beheben.

Daraus lässt sich schliessen, dass Programme, die unbedingt immer laufen müssen, malloc nicht benutzen dürfen.

Scheppertreiber Mitglied 09:25:08 09.03.2010 Titel:

Wieso ?

Unregistrierter

Scheppertreiber schrieb:

Wieso ?

Gamz einfach:
Wenn malloc scheitert, dann kann das Programm nicht vernünftig weiterarbeiten => Ein Programm, das ohne Störungen laufen soll, darf nicht auf malloc angewiesen sein.

_matze Mitglied 10:29:00 09.03.2010 Titel:

collam schrieb:

Scheppertreiber schrieb:

Wieso ?

Gamz einfach:
Wenn malloc scheitert, dann kann das Programm nicht vernünftig weiterarbeiten => Ein Programm, das ohne Störungen laufen soll, darf nicht auf malloc angewiesen sein.

Blödsinn. Wenn malloc scheitert, kann das auch nur bedeuten, dass ein bestimmter Zweig nicht ausgeführt werden kann. Deswegen die ganze SW abzuschiessen ist natürlich Quatsch, wenn der Benutzer doch weiterhin nutzen aus all den anderen Zweigen ziehen kann. Wenn man beispielsweise einen Editor mit vielen Freiheiten, was Speicherverbrauch angeht, bereitstellt, dann kann es durchaus passieren, dass der Benutzer soviele Felder platziert, bis kein Speicher mehr alloziert werden kann. Dann schlägt malloc fehl, er wird darüber informiert, der Editor läuft aber weiterhin und er kann noch weiterarbeiten (Datei speichern, vielleicht auch Felder löschen usw.).

pointercrash() Mitglied 10:31:13 09.03.2010 Titel:

Ich hatte auch mal so ein Phänomen bei einem Parser, der am PC lief und auf einem Controller crashte. Grund war tatsächlich das malloc(0), das sich unterschiedlich verhielt.

Bevor ich mich mit dem "unique" Pointer für die Blocksize 0 abplage, die dann ja wieder nur auf einem Compiler funktionieren würde, habe ich malloc(0) als Fall aussortiert, obwohl logisch kein Fehler dahintersteckte, wenn malloc(0) auf allen Kisten NULL zurückgeliefert hätte. Ist aber in der bösen Realwelt leider nicht so.

Nochwas: Wenn man Pointer immer mit NULL initialisiert und beim free() wieder auf NULL setzt, kann eigentlich nichts schiefgehen und vereinfacht den cleanup.

collam schrieb:

Wenn malloc scheitert, dann kann das Programm nicht vernünftig weiterarbeiten => Ein Programm, das ohne Störungen laufen soll, darf nicht auf malloc angewiesen sein.

Bullshit. Wenn malloc() fehlschlägt, heißt das, daß kein Speicher mehr frei ist, nicht mehr und nicht weniger. Bei obig erwähntem Parser gibt's den Fall auf dem Controller mehrfach und bedeutet nur, daß ich die Befehlsketten, die im Speicher schon bearbeitet sind, auf die SD- Karte weggeschrieben und gefreed werden sollen. Das ist keine Störung. :o)

Unregistrierter

_matze schrieb:

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?

_matze Mitglied 12:10:59 09.03.2010 Titel:

collam schrieb:

_matze schrieb:

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.

pointercrash() Mitglied 12:40:04 09.03.2010 Titel:

collam schrieb:

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.

Unregistrierter

_matze schrieb:

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.

Scheppertreiber Mitglied 16:39:43 09.03.2010 Titel:

collam schrieb:

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 ...

_matze Mitglied 16:44:30 09.03.2010 Titel:

collam schrieb:

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.

Scheppertreiber Mitglied 09:24:00 11.03.2010 Titel:

So ist es, Matze.

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