Heap und Stack

[Euklid]

Hallo Leute!

Ich habe da mal eine ganz allgemeine Frage:

In den Zeiten von TurboPascal 5 musste man bei seinen Programmen noch aufpassen, dass sehr begrenzten Speicherplatz des Stack nicht überschreitet. Benötigte ein Programm zusätzlichen Speicherplatz, musste man mit Pointern arbeiten und den Heap benutzen, wenn ich mich richtig erinnere.
Der Stack war dabei garnichtmal so groß, glaube 1 MB oder so.

Wie ist das denn heute bei FreePascal/Lazarus und anderen Sprachen? Ist der Stack immernoch derart begrenzt?
Muss ich damit rechnen, dass wenn ich unter "var" meine Variablen deklariere, irgendwann einen Stack-Overflow erreiche, obwohl die 512 MB RAM meines Rechners noch garnicht ausgefüllt sind?

Oder hat sich was geändert, der Stack ist nicht mehr begrenzt oder der Compiler kümmert sich darum?

Danke für die Antworten im Voraus!
Alexander

[theo]

Probier's doch aus. Da muss man immer noch aufpassen.

Code: Alles auswählen

type TmyArr=Array[1..100000] of integer; //gibt stack overflow
//type TmyArr=Array[1..100] of integer;  //das müsste klappen
 
{$S+} //Stack Checking einschalten
 
 
procedure TForm1.Button1Click(Sender: TObject);
var myArr:TmyArr;
begin
  Writeln('Hmm');
end;

[Euklid]

Ok, werde das Ergebnis dann hier posten...

[Euklid]

Ok, werde das Ergebnis dann hier posten...

... so. hat nun doch eine Weile gedauert. Um so überraschender das Ergebnis:

Definiert man mit Theos Typ TmyArr eine Variable, so kommt es zu einem "Unbekannter Fehler: 202", wenn man in den Compilereinstellungen den Stack überprüft - sonst nicht!

Dann habe ich das ganze Array dem Wert 53 bestückt. Dabei scheint kein Wert im Array verloren zu gehen - trotz Fehlermeldung.

hmmm. Wie habe ich das jetzt zu deuten?

[Euklid]

Hallo Leute,

hierzu gibt es jetzt eine eindeutige Antwort durch dieses Buch

http://www.cul.de/freepascal2.html" onclick="window.open(this.href);return false;

welches ich mir vergangene Woche zugelegt habe. Darin steht:

Bei Windows, Linux, FreeBSD und NetBSD ist die Stackgröße nur durch die Größe des verfügbaren Arbeitsspeichers begrenzt.

Sprich: Man braucht sich um den Stack keine Sorgen zu machen.

Das Buch ist übrigends wirklich empfehlenswert! Ich glaube, ich werde in den Osterferien mal eine Rezension o.ä. dazu für dieses Forum schreiben.

Viele Grüße, Euklid

[KOBOLD Messring GmbH]

Der Stack war dabei garnichtmal so groß, glaube 1 MB oder so.

16kB Stack-Default.
Mit 20 Adressleitungen eines 8088-Prozessors kann man _insgesamt_ nicht mehr als 1 MB adressieren. Bis 640K für Programme, 641-1024K für BIOS.
¿Wozu auch? "Es wird niemals Programme geben, die mehr als 64kB Arbeitsspeicher benötigen" (oder so, frei nach Bill Gates). Und ein IBM-Personal-Computer hat doch 640K, also für ¡¡ 10 Programme !! gleichzeitig, die man (ausser den Speicherresidenten) eh nicht gleichzeitig ausführen kann. ...mehr als ausreichend, hihihi

Na, ¿ wer kennt es noch ?
(läuft bei mir noch, in VMWare unter Mandriva)

[_Bernd]

Sprich: Man braucht sich um den Stack keine Sorgen zu machen.

ja und warum kommt es dann in dem Beispiel von theo zu einer Exception?

Gruß, Bernd.

[Euklid]

Sprich: Man braucht sich um den Stack keine Sorgen zu machen.

ja und warum kommt es dann in dem Beispiel von theo zu einer Exception?

Das ist eine gute Frage! Möglicherweise meldet die Option {$S+} garkeine Stack-Fehler - sondern nur, ob der für den Stack benötigte Speicherplatz einen gewissen Wert (z.B. 64kB) überschreitet?

Im FreePascal-Buch steht, dass die Stack-Überprüfung für Betriebssysteme mit begrenzter Stack-Größe notwendig ist (DOS, BeOS). Kann man daraus schließen, dass sie für Linux, Windows, FreeBSD, u.s.w. in keinem Fall aktiviert werden muss?

[pluto]

Ich dachte darum kümmern sich heutzutage die Modernen Betriebssysteme. Und lagern wenn nötig aus....

[af0815]

[quote="Euklid]Im FreePascal-Buch steht, dass die Stack-Überprüfung für Betriebssysteme mit begrenzter Stack-Größe notwendig ist (DOS, BeOS). Kann man daraus schließen, dass sie für Linux, Windows, FreeBSD, u.s.w. in keinem Fall aktiviert werden muss?[/quote]
Sie ist sinnvoll wenn man testen will, ob das programm nicht zuviel Heap verbraucht. Besonders gerne bei rekursionen kann man in schleifen kommen, wo der Heap sich ins Nirvana vergrössert. Da ist eine Notbremse oft hilfreich. In Produktivumgebungen NACH dem Testen wird wieder abgeschalten.

[Euklid]

Sie ist sinnvoll wenn man testen will, ob das programm nicht zuviel Heap verbraucht. Besonders gerne bei rekursionen kann man in schleifen kommen, wo der Heap sich ins Nirvana vergrössert. Da ist eine Notbremse oft hilfreich. In Produktivumgebungen NACH dem Testen wird wieder abgeschalten.

Hehe, da hast du natürlich Recht: Möchte nicht wissen, wie oft mein PC wegen des Speicherverzehrs rekursiver Schleifen schon abgestürtzt ist. Hierfür gibt es aber eine Überlaufprüfung, die unabhängig von der Stack-Überprüfung ist.

Euklid

[marcov]

Das ist eine gute Frage! Möglicherweise meldet die Option {$S+} garkeine Stack-Fehler - sondern nur, ob der für den Stack benötigte Speicherplatz einen gewissen Wert (z.B. 64kB) überschreitet?

Ich glaube dass ist das Problem. Kan man mit $M oder -Cs aendern.

Aber auch das System hat grenze glaub ich. Kann mann sehen mit ulimit -s, genau so wie ulimit -d den Datasegment Groesse gibt. ISPs setzen oft solchen Limieten auf Shell accounts.

[Euklid]

Aber auch das System hat grenze glaub ich. Kann mann sehen mit ulimit -s, genau so wie ulimit -d den Datasegment Groesse gibt. ISPs setzen oft solchen Limieten auf Shell accounts.

Aha - d.h. der Stack auf meinem System ist 8 MB groß.

Danke für die Information!

Euklid