StackTrace vs Code

[hyype]

Hallo Community,

ich habe seit geraumer Zeit mit Problemen zu kämpfen, deren Zustandekommen mir ein Rätsel ist.
Die Fehler werden in der Application.OnException-Routine abgefangen,
weil sie sich nicht per try..except an der auftretenden Stelle abfangen lassen.
Schon allein das verstehe ich nicht, aber es kommt noch besser.
Neben der Fehlermeldung wird der StackTrace mitgeloggt.
Zwei Arten von Fehlern können unterschieden werden:
1.) Zugriffsverletzung beim _Schreiben_ an der Stelle 00000000 beim Aufruf einer Methode, ohne dass er in die aufgerufene Methode reingeht.
2.) Beim Aufruf einer Methode kommt eine Exception (Privilegierte Anweisung) in einer völlig anderen Methode eines völlig anderen Objektes.

Für mich sieht es so aus, als wären die Pointer auf die Einstiegspunkte der Methoden oder gar die Methoden selbst im Speicher überschrieben worden.
Ich habe aber keine Ahnung, wodurch so etwas bewerkstelligt werden kann und weiß daher nicht, wonach ich suchen soll.
Das Programm ist schon sehr alt und _sehr_ häßlich und wurde vor geraumer Zeit von delphi7 auf XE2 umgestellt.

[Furtbichler]

Vollkommen falsch ist es, die Karre gegen die Wand fahren zu lassen, und aus den Trümmerteilen rekonstruieren zu wollen, was, wo und wann schiefgelaufen ist.

Das Problem ist die Stelle, die sich nicht mit Try-Except schützen lässt. Dort ist dann schon etwas schiefgelaufen, oder die Stelle ruft eine fehlerhafte DLL auf.

Zunächst würde ich prüfen, ob DLL verwendet werden. Dann die Bereichs- und Überlaufprüfung anschalten. FastMM dürfte dir weiterhelfen, weil es unter Anderem auch Stellen findet, bei der ein freigegebenes Objekt nochmals verwendet wird.

Wenn mit diesen Maßnahmen das Programm 'sauber' ist, sollte der Fehler eliminiert sein.

[Sir Rufo]

Ich würde das Programm mal im Debugger laufen lassen, dann hält der Code (meistens) an der richtigen Stelle an, sieht den aktuellen Inhalt der Variablen und über den angezeigten StackTrace sieht man die Aufrufreihenfolge.

[Furtbichler]

Zitat von Sir Rufo:

Ich würde das Programm mal im Debugger laufen lassen, dann hält der Code (meistens) an der richtigen Stelle an, sieht den aktuellen Inhalt der Variablen und über den angezeigten StackTrace sieht man die Aufrufreihenfolge.

Bei einer priviligierten Anweisung wohl weniger. Außerdem glaube ich, das er soweit auch schon war:

Zitat von hyype:

... weil sie sich nicht per try..except an der auftretenden Stelle abfangen lassen...Für mich sieht es so aus, als wären die Pointer auf die Einstiegspunkte der Methoden oder gar die Methoden selbst im Speicher überschrieben worden.

[hyype]

Hallo,

vielen Dank erstmal für die Antworten.
Die Bereichsprüfung und die Überlaufprüfung war nicht angehakt, dies habe ich nun getan, vielen Dank. Eine DLL wird nicht verwendet.

Zur Metapher:
Ich hatte gehofft, dass wenn statt Objekt1.MethodeA Objekt2.MethodeB aufgerufen wird
vielleicht abzusehen ist, was im Speicher schief gelaufen sein muss und sich somit mögliche Ursachen ableiten lassen.
Sicherlich kann man hier nur raten, da eine sinnvolle Fehleranalyse nicht möglich ist,
aber einer Theorie könnte man nachgehen und evtl den Fehler finden, ohne Theorie jedoch bleibt es für mich ein Mysterium.

[jaenicke]

Wenn du den Stacktrace und den Code zu der dort geloggten Methode posten würdest, könnten wir dir vielleicht auch direkt dabei helfen.
Wenn du das nicht öffentlich posten willst, kannst du es mir auch gern per PN schicken.

Sollte es wirklich ein Problem im Speicher sein, sprich überschriebener Speicher oder ähnliches, wäre FastMM sicher hilfreich. Das zeigt im FullDebugMode (einstellbar in der beiliegenden .inc Datei) dann bei Tests auch direkt z.B. Zugriffe auf freigegebene Objekte an, auch wenn es dabei sonst zufällig nicht direkt knallen würde.

[hyype]

Hallo,

die Prüfungen zu aktivieren war eine gute Idee, mit eingeschalteten Prüfungen hat das Programm keine 10s überlebt. ^^
Fehler war wie folgt:

Delphi-Quellcode:

var b  : byte;
    ab : array[1..1400] of byte;
    i  : integer;



  b := 0;
  for i := 1 to 1400 do
    b := b + ab[i];

Keine Ahnung, ob das böse Auswirkungen haben kann.
Nach Ausbau gab es keine Fehler mehr, das Programm lief, hat aber nicht mehr gemacht, was es sollte.
Mit deaktivierten Prüfungen hat es wieder gemacht, was es sollte.
Schade, hätte es gern mit aktivierten Prüfungen ein wenig laufen lassen.
FastMM habe ich noch nicht herangezogen.

@jaenicke:
Glaub mir bitte, dass der Code dir nicht hilft, die Fehler müssen woanders sitzen.

[p80286]

Das ist aber ungewöhnlich, 1400 Bytes in einem Byte zu addieren, das schreit ja geradezu nach Nebeneffekten.

versuch es mal so;

Delphi-Quellcode:

btemp:integer;

for i:=1 to 1400 do
  btemp:=btemp+ab[i];
btemp:=btemp and FF;
b:=btemp;

Gruß
K-H

[hyype]

die Lösung war noch besser:
die Stelle komplett ausgebaut, da das aufaddierte byte am Ende für nichts verwendet wurde.. ^^

[hyype]

Stacktrace:
(00005C68){blub.exe} [00406C68] System.TObject.InheritsFrom$qqrp17System.TMetaClas s (Line 13646, "System.pas" + 6) + $0
(0010B8FF){blub.exe} [0050C8FF] Vcl.ExtCtrls.Extctrls.TTimer.Timer$qqrv (Line 3056, "Vcl.ExtCtrls.pas" + 1) + $E
(0005A19C){blub.exe} [0045B19C] System.Classes.StdWndProc$qqsp6HWND__uiuiui + $14
(000279D0){blub.exe} [004289D0] System.SysUtils.Sysutils.ShowException$qqrp14Syste m.TObjectpv (Line 19109, "System.SysUtils.pas" + 15) + $15
(00028648){blub.exe} [00429648] System.SysUtils.Sysutils.ExceptHandler$qqrp14Syste m.TObjectpv (Line 19571, "System.SysUtils.pas" + 0) + $0

Stacktrace:
(00005C62){blub.exe} [00406C62] System.TObject.InheritsFrom$qqrp17System.TMetaClas s (Line 13642, "System.pas" + 2) + $0
(0010B8FF){blub.exe} [0050C8FF] Vcl.ExtCtrls.Extctrls.TTimer.Timer$qqrv (Line 3056, "Vcl.ExtCtrls.pas" + 1) + $E
(0005A19C){blub.exe} [0045B19C] System.Classes.StdWndProc$qqsp6HWND__uiuiui + $14

Ideen? ^^