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,

[negaH]

Zitat:

llerdings die entsprechenden Proceduren mit {$Q-}...{$Q+] klammern und immer den Standardwert wieder herstellen.

Nein so geht es nicht korrekt. Wenn dann so:

Delphi-Quellcode:

{$ifopt R+}
{ $define RangeCheckOn}
{$endif}

{$R-}
procedure OhneRangeCheck;
begin
end;
{$ifdef RangCheckOn $R+ $endif}

Man muß also selektiv erstmal abfragen ob $R+ aktiviert wurde und nur dann $R+ auch wieder einschalten, ansonsten würde man ja $R+ einschalten obwohl es vorher in den globalen Compilerswitches nicht aktiviert war.

Alternaiv kann man einen Switch lokal innerhalb der Procedure aktivieren, ich habe aber die Erfahrung gemacht das das je nach Compilerversion nicht richtig funktioniert bzw. Seiteneffekte provoziert.

Gruß hagen

[Hawkeye219]

Hallo,

in den Turbo-Pascal-Zeiten gab es für die Compilerschalter neben den Optionen "+" und "-" noch die Option "=", die den vorigen Zustand des Schalters wiederherstellte. Delphi bietet diese Möglichkeit leider nicht mehr, man kann sich aber relativ leicht behelfen, indem man für den betreffenden Schalter Include-Dateien im Bibliothekspfad bereitstellt und diese einbindet:

Delphi-Quellcode:

// Datei "R+.pas"

{$ifopt R-}
  {$undef RangeCheckIsOn}
  {$R+}
{$else}
  {$define RangeCheckIsOn}
{$endif}

// Datei "R-.pas"

{$ifopt R+}
  {$define RangeCheckIsOn}
  {$R-}
{$else}
  {$undef RangeCheckIsOn}
{$endif}

// Datei "R=.pas"

{$ifdef RangeCheckIsOn}
  {$R+}
{$else}
  {$R-}
{$endif}

Bei Verwendung dieser Include-Dateien sieht Hagens Beispiel so aus:

Delphi-Quellcode:

{$I R-}
procedure OhneRangeCheck;
begin
end;
{$I R=}

Gruß Hawkeye

[negaH]

Normalerweise müsste es auch so gehen

Delphi-Quellcode:

procedure OhneRangeCheck(params);
{$R-}
begin
end;

weil diese Switches dann nur lokale Gültigkeit haben sollten (per Definition). Leider hat das Nachteile da verschiedene Delphiversionen sich nicht daran halten oder zb. ausgehend von den übergebenen Parametern denoch ihren Rangcheck aktivieren. Zumal die Range/Overflowcheks mit jeder neueren Delphiversion immer unzuverlässiger werden, mal schlagen sie zu wenn es nicht richtig ist mal schlagen sie nicht zu wenn es richtig wäre.

PS: eine Include sollte die Extension .inc haben und nicht .pas ;)

Gruß Hagen

[Hawkeye219]

Hallo Hagen,

Zitat:

Zitat von negaH

[...]weil diese Switches dann nur lokale Gültigkeit haben sollten (per Definition).

Das sehe ich anders:

Zitat:

Zitat von Delphi-Hilfe

Lokale Direktiven betreffen nur den Teil der Compilierung, der sich von der Direktive bis zum nächsten Auftreten derselben Direktive erstreckt. Die Direktiven können an jeder beliebigen Position stehen.

Aus dieser Passage geht für mich eindeutig hervor, daß ein Bereich von zwei Compiler-Direktiven eingeschlossen wird.

Zitat:

eine Include sollte die Extension .inc haben und nicht .pas

Es mag gebräuchlich sein, zwingend vorgeschrieben ist es nicht:

Zitat:

Zitat von Delphi-Hilfe

Die Parameter-Direktive $I weist den Compiler an, die angegebene Datei in die Compilierung aufzunehmen. Diese Datei wird direkt nach der Direktive {$I Dateiname} in den Text eingefügt. Die vorgegebene Namenserweiterung für die Datei ist .pas.

Eine abweichende Namenserweiterung muß angegeben werden, die Erweiterung ".pas" kann entfallen. Der "Ersatz-Schalter" sieht damit fast aus wie sein Vorbild.

Gruß Hawkeye

[gammatester]

Zitat:

Zitat von negaH

Zitat:

llerdings die entsprechenden Proceduren mit {$Q-}...{$Q+] klammern und immer den Standardwert wieder herstellen.

Nein so geht es nicht korrekt. Wenn dann so:

Delphi-Quellcode:

{$ifopt R+}
{ $define RangeCheckOn}
{$endif}

{$R-}
procedure OhneRangeCheck;
begin
end;
{$ifdef RangCheckOn $R+ $endif}

Man muß also selektiv erstmal abfragen ob $R+ aktiviert wurde und nur dann $R+ auch wieder einschalten, ansonsten würde man ja $R+ einschalten obwohl es vorher in den globalen Compilerswitches nicht aktiviert war.

Alternaiv kann man einen Switch lokal innerhalb der Procedure aktivieren, ich habe aber die Erfahrung gemacht das das je nach Compilerversion nicht richtig funktioniert bzw. Seiteneffekte provoziert.

Gruß hagen

Nun, so geht's nun ganz bestimmt nicht:
1. Wir reden hier von Overflowcheck, also $Q+ oder $Q-
2. Dein {$ifdef RangCheckOn $R+ $endif} ist nicht sehr sinnvoll. Richtig wäre

Delphi-Quellcode:

{$ifdef RangCheckOn} {$R+} {$endif}

Also richtig

Delphi-Quellcode:

{$ifopt Q+}
  {$define TurnonQ}
  {$Q-}
{$else}
  {$undef  TurnonQ}
{$endif}

procedure OhneOverflowCheck;
begin
end;

{$ifdef TurnonQ}
  {$Q+}
{$endif}

Gruß Gammatester

[himitsu]

hatte es mal aus Interesse einfach getestet und...

Delphi-Quellcode:

Program Project1;

{$APPTYPE CONSOLE}

Uses SysUtils;

// wegen Compileroptimierung und Nutzungswarnung:
// If i = 0 Then ;

{$OVERFLOWCHECKS ON}

Procedure P1;
  Var i: Integer;

  Begin
    i := MaxInt;  If i = 0 Then ;
    Try
      Inc(i);  If i = 0 Then ;
      WriteLn('P1 - OverflowChecks OFF (global ON)');
    Except
      WriteLn('P1 - OverflowChecks ON (global ON)');
    End;
  End;

{$OVERFLOWCHECKS OFF}

Procedure P2;
  Var i: Integer;

  Begin
    i := MaxInt;  If i = 0 Then ;
    Try
      Inc(i);  If i = 0 Then ;
      WriteLn('P2 - OverflowChecks OFF (global OFF)');
    Except
      WriteLn('P2 - OverflowChecks ON (global OFF)');
    End;
  End;

Procedure P3;
  {$OVERFLOWCHECKS ON}

  Var i: Integer;

  Begin
    i := MaxInt;  If i = 0 Then ;
    Try
      Inc(i);  If i = 0 Then ;
      WriteLn('P3 - OverflowChecks OFF (global OFF, local ON)');
    Except
      WriteLn('P3 - OverflowChecks ON (global OFF, local ON)');
    End;
  End;

Procedure P4;
  Var i: Integer;

  Begin
    i := MaxInt;  If i = 0 Then ;
    Try
      Inc(i);  If i = 0 Then ;
      WriteLn('P4 - OverflowChecks OFF (global OFF)');
    Except
      WriteLn('P4 - OverflowChecks ON (global OFF)');
    End;
  End;

{$OVERFLOWCHECKS OFF}

Procedure P5;
  Var i: Integer;

  Begin
    i := MaxInt;  If i = 0 Then ;
    Try
      {$OVERFLOWCHECKS ON}
      Inc(i);  If i = 0 Then ;
      {$OVERFLOWCHECKS OFF}
      WriteLn('P5 - OverflowChecks OFF (global OFF, local ON)');
    Except
      WriteLn('P5 - OverflowChecks ON (global OFF, local ON)');
    End;
  End;

Procedure P6;
  Var i: Integer;

  Begin
    i := MaxInt;  If i = 0 Then ;
    Try
      Inc(i);  If i = 0 Then ;
      WriteLn('P6 - OverflowChecks OFF (global OFF)');
    Except
      WriteLn('P6 - OverflowChecks ON (global OFF)');
    End;
  End;

Begin
  P1;
  P2;
  P3;
  P4;
  P5;
  P6;
  ReadLn;
End.

tja, mit Lokal ala

Delphi-Quellcode:

procedure OhneRangeCheck(params);
{$R-}
begin

ist wohl nix :angel:

Code:

P1 - OverflowChecks ON (global ON)
P2 - OverflowChecks OFF (global OFF)
P3 - OverflowChecks ON (global OFF, local ON)
[color=#ff0000]P4 - OverflowChecks ON (global OFF)[/color]   [color=gray]<< 1[/color]
P5 - OverflowChecks OFF (global OFF, local ON)   [color=gray]<< 2[/color]
P6 - OverflowChecks OFF (global OFF)

1: hier hat wohl noch die P3 'ne Nachwirkung
2: hmmm ... irgendwie sollte hier doch auch ON stehn :shock: