Absturz bei malloc()
-
ist die anwendung vielleicht als 32bit kompiliert?
-
Hmm ich nutze den mingw compiler ob der jetzt 64 bit compiliert hab ich keine Ahnung, aber daran hab ich gar net gedacht...
-
edit:
Ja ich hab mingw32, gibt es eine Möglichkeit auf 64 bit zu compilieren?
-
So könnte es gehen:
pointer = malloc(1073741824 * sizeof(*pointer)); //Speicher reservieren fuer 1073741824 int(:warning:) reservieren
Mal davon abgesehen reservierst Du nur 1 GB (2^30 = 1073741824). Das reicht aber nur für 2^28 = 268435456 int-Werte (Bei der Annahme, dass Deine Plattform 32 Bit ints hat). In der Schleife versuchst Du aber 1073741824 int-Werte zuzuweisen. Dabei kracht es dann.
-
[cpp]
pointer = malloc(1073741824 * sizeof(int));
[/cpp]Nur der Ordnung halber ...
-
Raufasertapete schrieb:
nach gewisser Zeit Stürzt es dann ab und Windows versucht zeigt dann an: "pointer.exe funktioniert nicht mehr...."
du solltest den rückgabewert von malloc prüfen. wahrscheinlich ist der 0.
und versuchs mal, ob's mit winapi-funktionen wie 'VirtualAlloc' besser klappt. dann aber mit weniger. 0x100000000 bytes sind einfach 1 byte zu viel für 'nen 4GB adressraum. ausserdem muss der code ja auch noch irgendwo reinpassen, so'n pc basiert ja nicht auf der harvard-architektur.
-
Scheppertreiber schrieb:
[cpp]
pointer = malloc(1073741824 * sizeof(int));
[/cpp]Nur der Ordnung halber ...
Wenn pointer ein int* ist, dann ist das kein Unterschied zu sizeof(*pointer).
Wenn man allerdingsint* pointer
zu z.B.short* pointer
ändert muss man bei Deiner Variante an allen Stellen ändern, an denen allokiert wird. Bei meiner Variante muss man nur den Typ des Zeigers bei der Deklaration ändern.
-
Raufasertapete schrieb:
Ja ich hab mingw32, gibt es eine Möglichkeit auf 64 bit zu compilieren?
Mit gcc allgemein mit -m64, wenn das nicht geht kann's der MinGW evtl. (noch) nicht.
-
Deshalb die Korinthen. Des OPs Absturz hatte aber wohl andere Ursachen.
So einen riesenspeicher zu allokieren spricht gegen das was er vorhat, da
gibt's wohl schwächen im Algorythmus.
-
Scheppertreiber schrieb:
Deshalb die Korinthen. Des OPs Absturz hatte aber wohl andere Ursachen.
So einen riesenspeicher zu allokieren spricht gegen das was er vorhat, da
gibt's wohl schwächen im Algorythmus.Meinst Du "Weshalb die Korinthen"? sizeof(Variable von Typ) ist sizeof(Typ) vorzuziehen.
Er hat nur 1GB allokiert, und über die Buffergrenze hinaus geschrieben. Deshalb ist das Programm abgeschmiert. Das 4GB womöglich zuviel sind, steht auf einem anderen Blatt Papier. Btw. heisst es Algorithmus.
-
Scheppertreiber schrieb:
So einen riesenspeicher zu allokieren spricht gegen das was er vorhat, da gibt's wohl schwächen im Algorythmus.
Da gibts wohl eher Schwächen im lesen:
Raufasertapete schrieb:
PS: Auf (Un-)Sinn des Programms bitte nicht eingehen