[Allegro] acon crash

[Thomas Berger]

Lieber Herr Eversberg,

ein Update mit acon crashte bei mir mit "EXCEPTION-Error (memory access)",
was sich durch die Laenge des mit -O uebergebenen Benutzernamens
beeinflussen liess.

Grund duerfte sein, dass in abasew.cpp 36 Zeichen fuer den neuen
Datumsstempel reserviert werden, das genuegt nach den Aenderungen
im letzten Jahr aber nicht, denn das Datum ist weiterhin 17
Zeichen lang, fuer den Operator sind 32 reserviert, dazu kommt
noch die Kategorienummer,mit "#", der Trenner "▼o" und neu
auch noch "-" gefolgt von Satznummer, "/" und der ominoese
Speicherzaehler. In der Praxis gab es bereits ein Problem
bei Transaktion 1, 6stelliger Satznummer und Benutzernamen
von 9 Zeichen (sowie auch noch die abschliessende '0'?).

Wenn "a" also statisch dimensioniert werden muss (wie lang
kann eigentlich die Kategorienummer werden?), dann duerfte ein
unproblematischer Wert bei etwa 76 oder 80 liegen.


BTW: Ich hatte versucht, im fraglichen Job mit "Write" in
eine Datei moeglichst viel mitzuprotokollieren, und in
jenem update.job erfolgt auch der Versuch, alles auf
die Platte zu schreiben, bevor es kritisch wird:

if $OPTS.ProtocolFile var "+" $OPTS.ProtocolFile;export file
var ""
put

(es wird also bewusst mittels "export file" die Ausgabedatei
neu geoeffnet im Vertrauen darauf, dass der Flex-Interpreter
sie auch tatsaechlich schliesst und neu oeffnet. Das scheint
mir lt. Code in avjob.cpp auch der Fall zu sein, die
Protokolldatei ist allerdings im Falle des Exception-Errors
unvollstaendig, vermutlich weil Microsofts Laufzeitumgebung
ein "commit flag" kennt, das standardmaessig nicht gesetzt
ist und damit ein weiteres Zwischenspeichern durch die
Laufzeitumgebung erlaubt. Nach ANSI.C sollte fflush() bei
einem fclose() implizit sein und alles auf die Platte
schaufeln, mir ist leider nicht klar, ob Microsoft hier
von ANSI abweicht oder ob "die Platte" eintsprechend als
"Buffer der Laufzweitumgebung" abstrahiert wird. Man
koennte fopen() mit einem Microsoft-spezifischen Flag 'c'
ausstatten, oder mit setvbuf() das Buffern fuer diesen
Handle ausschalten.

Solche Dinge haben natuerlich drastische Auswirkungen auf das
Laufzeitverhalten (v.a. wenn das Buffern so stark abgestellt wird,
dass es garantiert auf der Platte landet, ~eigentlich~ wollen wir
die Daten aber nur aus der prozessgebundenen Laufzeitumgebung an
die Betriebssystem-Buffer weiterschieben), werden aber wichtig,
wenn etwas schief laeuft. Konfigurierbarkeit zur Laufzeit ueber
ein zu schaffendes Flex-Kommando ist gewiss knifflig, evtl. koennte
man eine Environmentvariable ALLEGRO_OPTS einfuehren, die beim Start
der Programme ausgewertet wird. Oder DEBUG-Versionen aller Module
standardmaessig mit ausliefern, die solche Schalter einstellen:
Das kann aber nach hinten loswerden, vgl.
< http://en.wikipedia.org/wiki/Heisenbug >.

viele Gruesse
Thomas Berger



viele Gruesse
Thomas Berger