Mathias hat geschrieben:Ich finde es gut, das es per Default deaktiviert ist. Wegen mir könnte man auch den Debugger deaktivieren. Da kommen sowieso im nur Fragen bei Anfängern, wieso die EXE so aufgebläht ist.
Wen jemand fortgeschritten ist, und weis wie das Debugging funktioniert, dann weis er auch wo man es einschaltet.
Weil Anfänger dies fragen, willst Du, dass Anfänger ihre Fehler (was Anfängern nun mal meist passiert) durchgehen? Das kann schnell zu viel mehr Fragen führen, und zwar jedes mal, wenn das Programm nicht stabil läuft, und zugleich auch von Lazarus dazu keine Fehlermeldung gibt. Und das wird dann besonders 'lustig' dann heraus zu finden, wo der Fehler liegt, während eine besser Einstellung der Debugger einem dies längst mitgeteilt hätte. Hinzu komme, je später man lernt, dass es so nicht gemacht werden darf, desto schwerer wird es, sich das richtige dann anzugewöhnen. Gerade für Neulinge sollte es daher jeden Fehler aufzeigen.
Und das mit der größeren Exe-Datei, dieses Unwissenheit kommt doch genau aus der selben Ecke wie die Einstellungen mit den Debugger: Fehlende Aufklärung. Es wird zu Lazarus viel geschrieben, vieles was banal ist, aber das wesentliche darf man mit der Lupe suchen. Anstatt auf den ersten Seiten, ist es irgendwo vergraben. Anstatt ausführlich erklärt, wird es nur kurz angesprochen.
Warf hat geschrieben:Mathias hat geschrieben:Zufällig war der Speicherbereich frei, ansonsten hättest eine SIGSEV gehabt.
Zufällig ist es nicht ganz, er befindet sich ganz oben auf dem Stack (welcher nach oben wächst) was also bedeutet, wenn er nach oben über den array schreibt müsste er schon über alle Stackframes drüber schreiben bis es zu einer Zugriffsverletzung kommt, und der stack ist in produktiven programmen für gewöhnlich recht groß. Daher ist es recht unwahrscheinlich bei Stack-Arrays eine Zugriffsverletzung zu bekommen.
Ich bekomme mit 15 in meinen Beispiel ja auch keine SIGSEV, sondern beim beenden des Programms eine verwirrende Fehlermeldung.
Warf hat geschrieben:Nein standardmäßig ist praktisch die minimale funktionalität gegeben um den GDB zu verwenden. Für kleinere sachen ausreichend, für größere Projekte würde ich einfach die Default Build-Modes Debug und Release verwenden.
Bin der Ansicht, der Debugger sollte so viele Fehler wie möglich finden. Erst recht bei Anfänger, damit die gleich das richtige Wissen, was eben geht, und was nicht, vermittelt bekommen. Anstatt Programme zu schreiben, die einem später dann unerwartet um die Ohren fliegen.
Warf hat geschrieben:Lazarus kann dir den Standard Release und Debug Modus per klick erstellen, die haben ziemlich gute voreinstellungen: Projekteinstellungen->Compilereinstellungen, oben Erstellmodi haken setzten, auf den ... button clicken und dann auf Debug Und Release Modus erstellen klicken. Den Default modus kannst du dann löschen.
Über die Dropdown box kannst du dann den aktiven modus wählen
Danke. Kann mich nicht erinnern, dass der wichtige Teil wo im Buch beschrieben war. Allerdings ist das wichtige ja eher versteckt, falls überhaupt darüber geschrieben wird, und belangloses am Anfang.
Warf hat geschrieben:Wie gesagt in den meißten fällen wird dir das Betriebsystem nicht genug speicher zur Verfügung stellen damit du überhaupt eine so genannte heap collision (stack der nach oben wächst und heap der nach unten wächst überschneiden sich) bekommen kannst. Man muss schon aktiv, mit administratorrechten das bei seinem Betriebsystem einstellen damit man da was kaputt machen kann.
Wie ich bereits selber sagte: Blicke da eh nicht so ganz durch. Aber genau das ist immer das Gefährliche, wenn Jemand etwas nicht selber erklärt (in dem Fall Lazarus/-Buch etc.), sondern es anderen überlässt. Irgendwann müssen die dann doch erklären, was die Wahrheit ist und haben viel Aufräumarbeit (Beseitigung von Falschinfos und Überzeugung) dann vor sich.
Warf hat geschrieben:Das hauptproblem für eine Stacküberlauf sind aber auch keine angreifer, sondern dumme programmierer. z.B funktionen mit großem stack:
Code: Alles auswählen
procedure SomeRecursiveProcWithVeryLargeStack(i: Cardinal);
var arr: array[0..1000000] of Byte; // 1MB stack size
begin
if LongBool(i) then SomeRecursiveProcWithVeryLargeStack(i-1);
end;
Ein entsprechend großes i würde dir damit eine heap collisiob geben. Aber, mit dynamischen arrays oder pointer auf statische arrays und new-dispose, wäre das ganze kein problem
Moment mal, soll das heißen, dass allein die Größe für einen Überlauf sorgt? Wenn ich jetzt zum Beispiel folgendes machen würde:
Code: Alles auswählen
var arrd3: array[1..1000000,1..20] of Integer; // also mind. 20 MB, würde das dann auch einen Überlauf verursachen?
Warf hat geschrieben:Es bräuchte einfach eine vernünftige Wikiseite die alles wenigstens kurz erklärt (und vor allem alles auf einer Seite)
Sehe ich genau so. Und falls es die bereits gibt, so scheint die dann gut versteckt zu sein.
Man kann die Fehlermeldung auch im Terminal ausgeben lassen? Also davon bin ich nicht begeistert. Immerhin wirken sich Befehle im Terminal ja auf das BS aus. Das ist mir einfach zu gefährlich.
Jedenfalls Danke. Jetzt weiß ich schon wieder einiges mehr. Besonders das mit den Voreinstellungen der Debuggeinstellungen scheint interessant zu sein. Damit kann man dann also vorgefertigte Einstellungen abspeichern und auswählen? Und somit ganz einfach Tagsüber eine schnelle Einstellung auswählen, und gegen ende des Tages jene, die alles noch mal ordentlich überprüft, ohne dass man jedes mal explizit die Hacken überall umsetzten muss? Werde ich mir heute noch ansehen.