Try-Except Raise funktioniert nicht richtig

schippi · Beiträge: 23

Hi!

Zitat:

Die können gar keine größeren Frames als 64KB transportieren; dein "2GB-Problem" ist damit also definitiv (zumindest auf Frame-Ebene des NBFPA) unmöglich.

Ich übertrag ja mehrere Frames. Werden beispielsweise 150000 Bytes übertragen, dann ist "size=150000" und die Daten werden halt auf 3 Frames aufgeteilt. Eigentlich sogar 4. Size kommt in einen extra Frame.
Sooo der Plan bis jetzt :wink:

Viele Grüße

alzaimar · Verfasst: Di 23.10.07 08:16

Ihr habt aber -glaube ich- das Problem einfach umschifft, indem ihr sagt: Das kann so nicht passieren. Das mag stimmen, aber die Frage bleibt: Wieso schmiert die Anwendung einfach ab und ist nicht in der Lage, die Exception so zu behandeln, wie sie sollte? :nixweiss:

_________________
Na denn, dann. Bis dann, denn.

Narses · Verfasst: Di 23.10.07 12:11

Moin!

alzaimar hat folgendes geschrieben:

die Frage bleibt: Wieso schmiert die Anwendung einfach ab und ist nicht in der Lage, die Exception so zu behandeln, wie sie sollte? :nixweiss:

Das sehe ich auch so.

Allerdings habe ich hierzu noch nix weiter gehört, und da vermute ich den Fehler:

Narses hat folgendes geschrieben:

Weiterhin könnte dein Code selbst "komisch" reagieren, wenn die Programmteile nach der Exception - die dann ja nicht durchlaufen werden - irgendwelche Datenstrukturen hätten initialisieren sollen, das aber nicht erfolgt ist und du später versuchst, darauf zuzugreifen. :idea:

[...]
Weiterhin gilt:

Narses hat folgendes geschrieben:

Aber ohne den Code zu kennen, kann ich nicht mehr dazu sagen. :nixweiss:

schippi hat folgendes geschrieben:

Ich übertrag ja mehrere Frames. Werden beispielsweise 150000 Bytes übertragen, dann ist "size=150000" und die Daten werden halt auf 3 Frames aufgeteilt. Eigentlich sogar 4. Size kommt in einen extra Frame.

Was machst du denn mit den Daten? Alle im RAM lagern? :gruebel:

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

schippi · Beiträge: 23

Hallo!
Das mit dem Code ist ein bißchen schwierig, weil der Code ziemlich umfangreich ist, es jetzt funktioniert und ich nicht genau weiß woran es genau lag. Aber ich benutze einige male "System.Move()" und das könnte meiner Meinung nach nicht ganz unkritisch sein, falls der reservierte Speicherbereich überschritten wird.
Hier z. B. mal was, das trotz Try-Except eine AccessViolation auslöst.

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:

Procedure TForm1.Button1Click(Sender: TObject);
Var
  CheckSum: PByte;
  TestW: Word;
  SizeCheckSum, TestInt, Zahl: Integer;
Begin
  TestW := 999;
  TestInt := 100;
  Zahl := 3;
  Try
    SizeCheckSum := 7;
    GetMem(CheckSum, SizeCheckSum);
    FillChar(CheckSum^, SizeCheckSum, 0);

    System.Move(Pointer(@TestW)^, CheckSum^, 2);
    inc(CheckSum, 4);
    System.Move(Pointer(@TestInt)^, CheckSum^, 4); // Daten kopieren
    Inc(CheckSum, 4);
    System.Move(Pointer(@Zahl)^, CheckSum^, 4); // Daten kopieren
    Inc(CheckSum, 4);
    System.Move(Pointer(@Zahl)^, CheckSum^, 4); // Daten kopieren
    Inc(CheckSum,19);

    Dec(Checksum, SizeCheckSum);

    FreeMem(CheckSum, SizeCheckSum);
  Except
    showmessage('a');
  End;
End;

Beim ersten mal, wenn man den Button1 drückt funktionierts und beim 2. mal nicht mehr. Falls es trotzdem immer funktioniert, einfach mal die Werte bei Inc ein bißchen ändern.

Zitat:

Was machst du denn mit den Daten? Alle im RAM lagern?

Ich bekomme die Daten, kopiere sie in einen String (wo wir wieder bei system.move wären :wink:

), bilde die Checksum und falls die stimmt, übergeb ich den String einer Funktion in einer DLL.

So kopiere ich die Daten in den String:

markieren

Delphi-Quelltext

1:
2:

  SetLength(Data, DataLength);
  System.Move(PChar(PA.Inbound.Strings[5])^, Pointer(@Data[1])^, DataLength);

Grüße

Narses · Verfasst: Di 23.10.07 14:19

Moin!

schippi hat folgendes geschrieben:

Aber ich benutze einige male "System.Move()" und das könnte meiner Meinung nach nicht ganz unkritisch sein, falls der reservierte Speicherbereich überschritten wird.

Wenn du das doch schon weißt, warum gehst du dann nicht entsprechend vorsichtig damit um?!

schippi hat folgendes geschrieben:

Hier z. B. mal was, das trotz Try-Except eine AccessViolation auslöst.

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:

Procedure TForm1.Button1Click(Sender: TObject);
Var
  CheckSum: PByte;
  TestW: Word;
  SizeCheckSum, TestInt, Zahl: Integer;
Begin
  TestW := 999;
  TestInt := 100;
  Zahl := 3;
  Try
    SizeCheckSum := 7;
    GetMem(CheckSum, SizeCheckSum);
    FillChar(CheckSum^, SizeCheckSum, 0);

    System.Move(Pointer(@TestW)^, CheckSum^, 2);
    inc(CheckSum, 4);
    System.Move(Pointer(@TestInt)^, CheckSum^, 4); // Daten kopieren
    Inc(CheckSum, 4);
    System.Move(Pointer(@Zahl)^, CheckSum^, 4); // Daten kopieren
    Inc(CheckSum, 4);
    System.Move(Pointer(@Zahl)^, CheckSum^, 4); // Daten kopieren
    Inc(CheckSum,19);

    Dec(Checksum, SizeCheckSum);

    FreeMem(CheckSum, SizeCheckSum);
  Except
    showmessage('a');
  End;
End;

Beim ersten mal, wenn man den Button1 drückt funktionierts und beim 2. mal nicht mehr. Falls es trotzdem immer funktioniert, einfach mal die Werte bei Inc ein bißchen ändern.

Und du wunderst dich tatsächlich, dass das nicht richtig funktioniert?! :roll:

Ich möchte hier sicherheitshalber einmal kurz klarstellen, dass das überhaupt nix mit den TNBFPA-Komponenten zu tun hat, wenn dein Code bei solchen Aktionen abschmiert!

cu
Narses

//EDIT: "bei solchen Aktionen" in den letzten Satz eingefügt.

_________________
There are 10 types of people - those who understand binary and those who don´t.

Lossy eX · Beiträge: 1048 Erhaltene Danke: 4

Narsens: Also ich würde von meinem Code nie behaupten, dass er vollkommen fehlerfrei ist. Sondern immer, dass er keine offensichtlichen Fehler mehr enthält. Alles Andere kann man nie mit Gewissheit sagen. Nur nahezu ausschließen.

Schippi: Nichts destro trotz teile ich Narsens Meinung. Mich würde mal interessieren was du mit dem Code vor hast? Willst du nur einen Fehler produzieren? Dann wäre der Zugriff auf einen nil pointer die bessere Alternative. Denn das erzeugt genau nur eine Zugriffsverletzung und du zerstörst damit keine fremden Speicherbereiche.

Denn nichts anderes tust du da. Du schreibst willenlos in anderen Speicherbereiche und gibst davon auch noch Stücke frei, denn 4 + 4 + 4 + 19 sind nicht 7. Und damit erreichst du lediglich, dass die Intigrität anderer Programmteile nicht mehr gewährleistet werden kann.

Der Speichermanager von Delphi alloziiert größere Speicherbereiche und bei GetMem wird ein kleineres Stück davon zurückgegeben. Wenn du jetzt eine Zugriffsverletzung bekommst dann besagt die lediglich, dass du außerhalb eines von Delphi kontrollierten Bereiches zugreifen wolltest. Wenn dein Pointer aber genau innerhalb eines solchen Blockes liegt hast du noch einige Kilobytes (keine Ahnung wie viel genau) in denen andere Daten von deinem Programm stecken können. Wenn du Glück hast wird der Block nicht benutzt. Dann passiert rein gar nichts. Aber ansonsten kann so ziemlich alles passieren.

[Edit] Was ich ganz vergessen habe. Dadurch dass du andere Bereiche veränderst schaffst du es natürlich solch einen Try Except Block zu umgehen, da du zwar noch im Speicher von Delphi bist aber die Daten von Programmcode zerstört hast die auf so etwas nicht gefasst sind. Also die nicht in einem Try Except Block liegen. Aus Geschwindigkeitsgründen etc. Das bedeutet der Fehler kommt eigentlich woanders her wird aber vor dir hervorgerufen.

_________________
Nur die Menschheit ist arrogant genug, um zu glauben sie sei die einzige intelligente Lebensform im All. Wo nicht mal das nachhaltig bewiesen wurde.

Narses · Verfasst: Di 23.10.07 15:06

Moin!

Lossy eX hat folgendes geschrieben:

Narsens: Also ich würde von meinem Code nie behaupten, dass er vollkommen fehlerfrei ist. Sondern immer, dass er keine offensichtlichen Fehler mehr enthält. Alles Andere kann man nie mit Gewissheit sagen. Nur nahezu ausschließen.

Hast ja recht, war nur so geschockt.

Hiermit ziehe ich also öffentlich die Fehlerfreiheit meines Codes wieder in den bezweifelbaren Bereich.

habe meinen Code nie als grundsätzlich Fehlerfrei hingestellt - hätte man aber vielleicht in meinem letzten Post so lesen können, OK

Lossy eX hat folgendes geschrieben:

Schippi: Nichts destro trotz teile ich Narsens Meinung. Mich würde mal interessieren was du mit dem Code vor hast?

Das würde mich allerdings auch interessieren. :gruebel:

cu
Narses

//EDIT: @ user profile icon

Lossy eX: Danke für die Erläuterungen; hätte ich auch mal machen können, statt mich aufzuregen... :oops:

Also, "Sorry" an user profile icon

schippi

_________________
There are 10 types of people - those who understand binary and those who don´t.

schippi · Beiträge: 23

Hallo Narses!
Mir ist schon klar, dass man damit vorsichtig umgehen muss und dass das nicht funktioniert..

Hab halt verschiedene Fehlerfälle durchgespielt und da war auch der Fehler mit System.move dabei. Dachte dass sich das trotzdem irgendwie abfangen lässt, wenn so was mal passieren sollte. Weiß halt nicht wie und habs deswegen hier gepostet.

Zitat:

Ich möchte hier sicherheitshalber einmal kurz klarstellen, dass das überhaupt nix mit den TNBFPA-Komponenten zu tun hat, wenn dein Code abschmiert!

Ich wollte nicht, dass das so rüberkommt, als wäre deine Komponente daran Schuld.
Ich hab deine Socketkomponente nur angesprochen, weil sich das Try-Except mit Einbinden der Komponente anders verhielt als ohne und ich wusste nicht warum. Da du ja in diesem Forum bist und es wahrscheinlich am besten weißt...

Ich hoffe, ich hab jetzt nochmal die Kurve gekriegt :wink:

Lossy eX · Beiträge: 1048 Erhaltene Danke: 4

Narsens: War auch nicht ganz ernst gemeint.

Schippi: Okay. Fehlerfälle durchspielen ist durchaus ein Argument. Allerdings löst dein Code ja nicht direkt den Fehler aus sondern nur indirekt und damit nützt das Try Except in dem Falle gar nichts. Außer du würdest auf ungültigen Speicher zugreifen.

Aber einige Fehlerfälle dürfen auch einfach nicht passieren. Zum Beispiel wenn du an die Adresse deiner lokalen Variable schreibst. Zum Beispiel ein lokales statisches Array. Dann befinden sich diese Daten auf dem Stack und wenn du dort rüber schreibst kann es passieren, dass du dir die Daten des Try Except Blockes zerschießt was dann zur Folge hat dass Delphi nicht mehr weiß was es machen soll. Und schwupp ist deine gesammte Anwendung weg.

Besser ist es sich genau Gedanken zu machen was passieren könnte und darauf so gut wie möglich zu reagieren. Testen kann man leider sowieso nicht alles.

_________________
Nur die Menschheit ist arrogant genug, um zu glauben sie sei die einzige intelligente Lebensform im All. Wo nicht mal das nachhaltig bewiesen wurde.

schippi · Beiträge: 23

Zitat:

Also, "Sorry" an schippi :beer:

Kein Problem! Hab halt auch blöd gefragt, dann bekommt man ja bekanntermaßen auch ne blöde Antwort :wink:

Also wenn jemand noch ein dümmerer Fehler einfällt als mir, dann her damit. Ich bring dann damit mein Programm zum Absturz und frag anschließend Narses, was mit seiner Komponente nicht stimmt :zwinker:

Viele Grüße

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme