MD5-Hash wirft Integer-Überlauf Exception (EIntOverflow)

[s.h.a.r.k]

Guten Morgen erst mal,

ich sitze zurzeit an einem sehr komischen Problem: Und zwar handelt es sich darum, dass ich über die Unit, welche ich in den Anhang gesteckt habe, einen MD5-Hash ausgeben lassen will. Bisher, d.h. so circa 2 Monate lang ging es auch ohne Problem, nur seit gestern macht die Unit zicken und wirft mit jedes Mal, wenn ich die Anwendung ausführe eine EIntOverflow-Exception. Ich weiß nicht mehr weiter... Vor allem, weil es bisher wunderbar funktioniert hat.

In Zeile 111 erscheint dann der folgende Fehler:

Zitat:

---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt s.m.i.l.e.exe ist eine Exception der Klasse Exception mit der Meldung 'Benutzer existiert nicht' aufgetreten.
---------------------------
Anhalten Fortsetzen Hilfe
---------------------------

hier die Methode, in der der Fehler auftritt

Delphi-Quellcode:

{Z:109} procedure FF(var a: DWORD; b, c, d, x: DWORD; s: BYTE; ac: DWORD);
{Z:110} begin
{Z:111}    inc(a, F(b, c, d) + x + ac); // <<< hier tritt der Fehler auf...
{Z:112}    rot(a, s);
{Z:113}    inc(a, b);
{Z:114} end;
// Die Werte:
// a  = 1732584193
// b  = 4023233417
// c  = 2562383102
// d  = 271733878
// x  = 128
// s  = 7
// ac = 3614090360

Noch ein paar Informationen:
- wir sind eine Gruppe von Programmieren, d.h. ich kann nicht genau sagen wer, was, wann, wie geändert hat!
- das Projekt umfasst doch mehrere tausend Zeilen
- wir arbeiten mit der BDS 2006 (ohne Updates, soweit ich weiß)
- ich habe die Unit aus dem Internet geladen und daran nicht geändert!
- Ich habe auch schon andere Units getestet, mit dem selben Fehler!

Ich hoffe Ihr könnt mir hierbei weiterhelfen. Ich bin echt am verzweifeln :wall:

Mit freundlichen Grüßen
der Hai

[edit] Schreibfehler gefunden und für schlecht empfunden ;) [/edit]

[s.h.a.r.k]

Hey,

ich könnt echt die Wand hochlaufen... Hab den Fehler selbst gefunden :wall: schon toll, dass jemand an den Projekteinstellungen rumgedreht hat.

Man kann dort unter den Compiler-Einstellungen (nicht Compiler-Meldungen) die Laufzeitfehler einstellen. Dort war ein Haken bei der Überlaufprüfung gesetzt, welcher dort nicht stehen sollte. >>> Haken rausgenommen, keinerlei Fehler mehr, Programmierer glücklich ;)

Mit freundlichen Grüßen
der Hai

[Muetze1]

Zitat:

Zitat von s.h.a.r.k

- wir sind eine Gruppe von Programmieren, d.h. ich kann nicht genau sagen wer, was, wann, wie geändert hat!

Dann haben wir hier ein gutes Beispiel für eine Quellenverwaltung (RCS, CVS, SubVersion, etc), dann könntest du alle Änderungen und deren Autoren nachvollziehen.

Zitat:

Zitat von s.h.a.r.k

Dort war ein Haken bei der Überlaufprüfung gesetzt, welcher dort nicht stehen sollte.

Eigentlich sollte er zur Entwicklungszeit schon dort stehen. Das ausnutzen des Überlaufs muss mit gutem Wissen geschehen. Wenn dabei mal ein Datentyp geändert wird etc, dann ist ein komplett anderes Verhalten beim Überlauf. Im Normalfall sollte kein Überlauf stattfinden und wenn doch, so kann man dies ohne Ausnutzung eines solchen umstellen, z.B. durch MODulo. Ich kenne bisher noch keinen Code, der einen Überlauf benötigte.
Ansonsten wenn der Überlauf gewollt ist, dann sollte man die Überlaufprüfung nur für den Bereich abschalten und für das Projekt als solches aber einschalten. Gleiches gilt für die Bereichsprüfung!

[Union]

Man sollte dann eher {$R-} verwenden. Es kann ja sein, dass jemand anderes den globalen Schalter gesetzt hat, weil er will dass in den von ihm programmierten Modulen Exceptions auftreten und entsprechen abgefangen werden. In den von ihm erstellten Sourcen sollte dann explizit {R+} eingefügt werden.

[Muetze1]

Zitat:

Zitat von Union

Man sollte dann eher {$R-} verwenden. Es kann ja sein, dass jemand anderes den globalen Schalter gesetzt hat, weil er will dass in den von ihm programmierten Modulen Exceptions auftreten und entsprechen abgefangen werden. In den von ihm erstellten Sourcen sollte dann explizit {R+} eingefügt werden.

Standardmäßig aus und nur die zu überprüfenden Bereich an? Nach welcher Logik denn dies? Ich habe die Projektoptionen und wenn ich dort global einstelle, dass ich die Überlaufprüfung haben will, da ich das gesamte Projekt testen will, dann soll das so sein. Mit deinem Vorschlag wäre diese Option nutzlos. Grundsätzlich sollte man sicheren Code programmieren, von daher während der Entwicklung mit eingeschalteter Überlaufprüfung und Bereichsprüfung. Wenn ein Code definitiv immer eins von beiden verletzt, der Code aber sicher ist (bzw. das Verhalten gewollt ist), dann kann man den Teil mit Compilerschaltern rausnehmen.

Der Sinn und Zweck dieser Compilerschalter ist doch Codestellen zu finden, welche nicht ordentlich funktionieren bzw. sich ungewollt verhalten. Wenn du explizit Codebereiche fest markierst, welche überprüft werden sollen, dann blendest du haufenweise anderen Code aus, welcher genau solche Problemfälle beinhaltet. Wenn ich schon weiß wo der Fehler liegt, ist das ok, aber die Optionen sollen doch helfen Code zu finden, wo man keinen Fehler vermutet, dieser aber trotzdem welche enthält.

$R ist die Bereichsprüfung und nicht die Überlaufprüfung!

[Union]

Zitat:

Zitat von Muetze1

Standardmäßig aus und nur die zu überprüfenden Bereich an? Nach welcher Logik denn dies?

Weil ich mich auf den konkreten Fall bezogen habe. Ursprünglich war ja wohl die Prüfung global abgeschaltet, ich setze voraus, dass dies einen Grund hatte.

Zitat:

Zitat von Muetze1

$R ist die Bereichsprüfung und nicht die Überlaufprüfung!

Sorry, ich meinte {$Q} :oops:

[0x802b]

Du könntest auch folgendes mal probieren...

Delphi-Quellcode:

procedure FF(var a: DWORD; b, c, d, x: DWORD; s: BYTE; ac: DWORD);
begin
  a:=a+F(b, c, d) + x + ac;
  rot(a, s);
  a:=a+b;
end;

Damit lässt sich meine MD5 zumindest compilen,auch mit den genannten Prüfroutinen..

[s.h.a.r.k]

Compilieren lies es sich immer! Nur während der Laufzeit hab ich dann die Exception bekommen. Hätte ich wohl noch dazu erwähnen können :oops:

[gammatester]

Bei MD5 (und den meisten anderen Hashalgorithmen) MUSS {$Q-} gesetzt sein, weil dort Integerarithmetik mod 2^32 benutzt wird, und mit 32Bit-Arithmetik Überlaufe praktisch immer vorkommen. Die Alternative wäre 64-Bit-Arithmetik und nach jeder Operatiion ein and $FFFFFFFF dazu programmieren.

Damit ist aber die Performance ziemlich runter und übersichtlicher ist es auch nicht. Man muss halt wissen was man macht, und hier ist {$Q-} definitiv angebracht. Man kann allerdings die entsprechenden Proceduren mit {$Q-}...{$Q+] klammern und immer den Standardwert wieder herstellen.

Gruß Gammatester

[himitsu]

Zitat:

Zitat von 0x802b

Du könntest auch folgendes mal probieren...

Delphi-Quellcode:

a:=a+F(b, c, d) + x + ac;

Damit lässt sich meine MD5 zumindest compilen,auch mit den genannten Prüfroutinen..

ja klar, aber da de Fehler ja an der Überlaufprüfung lag, wird er hier genauso auftreten ... an der Rechenweise hat sich ja nix geändert.

alternativ könnte ich noch negaH's DEC empfehlen, dort wird per ASM gearbeitet und die Fehlerprüfung somit umgangen.
eine Implementation ist ebenfalls in ASM, also auch keine Probleme
und zu guter Letzt könnte man sich auch direkt an Windows wenden, dessen Implementation (seit Win2000 immer dabei) hat auch nicht soclhe Problemchen,