Programm-Absturz seit Delphi 11.2

[atari1040]

Zitat von Uwe Raabe:

...

Ich will hier ja gar nicht die vorhandenen Fehler klein reden, aber wenigstens den ersten Schritt tun und den Fehler melden und, falls nötig, mit dem Hersteller oder hier im Forum daran arbeiten, ihn zu reproduzieren sollte man erwarten können. Eine Rückmeldung "passiert hier nicht" ist nur eine anderen Formulierung für "es fehlen noch weitere Informationen um den Fehler zu reproduzieren". Das kann manchmal schwierig werden, ist aber für die Behebung notwendig. Wie schon gesagt, beim HSV kannst du vermutlich nichts tun, bei Delphi aber schon.

Uwe, dass hört sich alles schön an was Du schreibst und Du wirst bestimmt viel Beifall dafür bekommen. In diesem Fall treffe ich aber die Entscheidung, was ich in meiner Arbeitszeit mache. Produktiv für den Kunden sein oder ehrenamtlich dem Delphi Hersteller beim Versuch helfen, eine stabile IDE zu entwickeln. Woher weisst Du, wieviele Fehler ich in den letzten Jahrzehnten gemeldet habe? Mein größtes Problem mit Delphi ist die Laufzeit der Fehlerbehebung, die vielleicht sogar kommerzielle Gründe hat. Man fühlt sich schon wie in einer Abo Falle. Dein Fehler wird behoben, wenn Du verlängerst. Seit Delphi 11 draussen ist friert die IDE ein, wenn Du alte Projekte laden möchtest und eine Komponente nicht installiert ist. Die Frage ist dann, welche Komponente, denn darüber schweigt sich die eingefrorene IDE aus. Nein Uwe, zum Glück treffen wir die Entscheidung, welche Entwicklungsumgebung wir einsetzen. Dein Ziel, Delphi zu verbessern in allen Ehren aber mein Ziel kann nach den gemachten Erfahrungen nur noch die Umstellung aller Projekte auf eine andere Architektur sein. Bis dahin muss ich mich wohl mit den Problemen quälen.

[Uwe Raabe]

Zitat von atari1040:

Woher weisst Du, wieviele Fehler ich in den letzten Jahrzehnten gemeldet habe?

Das weiß ich natürlich nicht und meine Aussage bezog sich auch eher auf diese Bemerkung:

Zitat von rwalper:

So warte nun auf das nächste Update von Emba und DevExpress in der Hoffnung, dass es dann läuft

Als ob nur abzuwarten hier irgendetwas bringen würde.

Zitat von atari1040:

Seit Delphi 11 draussen ist friert die IDE ein, wenn Du alte Projekte laden möchtest und eine Komponente nicht installiert ist. Die Frage ist dann, welche Komponente, denn darüber schweigt sich die eingefrorene IDE aus.

Das hört sich jetzt so an, als wäre das immer der Fall. Meine eigene Erfahrung ist aber eine andere (gerade nochmal probiert). Die Ursache ist also nicht generell das Laden eines alten Projekts mit einer nicht installierten Komponente, sonder es muss noch etwas anderes involviert sein. Wenn du mir die entsprechenden QP-Einträge nennst, will ich da gerne mal reinschauen.

Zitat von atari1040:

mein Ziel kann nach den gemachten Erfahrungen nur noch die Umstellung aller Projekte auf eine andere Architektur sein.

Nun gut, wenn du diese Entscheidung bereits getroffen hast, kann ich verstehen wenn für dich die Behebung der Fehler nicht mehr von Belang ist. Ich wünsche dir bei deiner Umstellung viel Erfolg.

[walterschmitt]

Zitat:

Dir ist aber schon klar, dass da jetzt immer noch ein Fehler im Code vorliegt, oder?
Das ist in etwa so sinnvoll wie das generelle Abschalten des Range-Checking, weil das sporadisch zu unerklärlichen Fehlern führt.

Ist mir schon klar, aber wie schon vorher geschrieben den Fehler verursacht eine Fremd-Komponente.
Ich habe denen ein Beispielcode gesendet, der läuft dort aber ohne Probleme.

[Fritzew]

Zitat von walterschmitt:

Ist mir schon klar, aber wie schon vorher geschrieben den Fehler verursacht eine Fremd-Komponente.
Ich habe denen ein Beispielcode gesendet, der läuft dort aber ohne Probleme.

Tja, liegt die Komponente im Source vor? Dann würde ich wirklich schauen was die Ursache ist.
Mit dem Wissen eines solchen Fehlers würde ich nicht mehr ruhig schlafen. Nur weil es bei Dir nicht mehr auftritt ist das Problem nicht gelöst!

[jaenicke]

Zitat von walterschmitt:

Zitat:

Dir ist aber schon klar, dass da jetzt immer noch ein Fehler im Code vorliegt, oder?
Das ist in etwa so sinnvoll wie das generelle Abschalten des Range-Checking, weil das sporadisch zu unerklärlichen Fehlern führt.

Ist mir schon klar, aber wie schon vorher geschrieben den Fehler verursacht eine Fremd-Komponente.
Ich habe denen ein Beispielcode gesendet, der läuft dort aber ohne Probleme.

Das Problem an der Geschichte ist, dass ASLR dazu führt, dass z.B. Fehler auffallen, die bisher nur nicht aufgefallen sind, weil an fehlerhaft zugegriffenen Speicherpositionen Werte standen, die keinen Fehler verursachten. Diese Speicherfehler müssen aber nicht unbedingt an der Stelle entstehen, an der sie auftreten.

Heißt: Nur weil der Fehler in einer externen Komponene auftritt, heißt das nicht, dass er auch dort verursacht wird. Es kann also durchaus sein, dass der Fehler in dem eigenen Code liegt und sich nur in einer solchen Komponente äußert.

Finden lassen sich solche Fehler auf zwei Wegen:
Entweder man kann vorhersagen, welche Speicherstelle falsch angesprochen wird, dann kann man miit Datenhaltepunkten arbeiten.

Oder es bleibt (neben sehr aufwendigen Analysen, die man eher nicht machen möchte) nur folgender Weg: Man entkernt die Anwendung bis man den Fehler nicht mehr reproduzieren kann. Dann macht man die Änderung rückgängig, bis man es wieder reproduzieren kann, und entfernt dann andere Teile.
Am Ende hat man entweder ein Demoprogramm für einen externen Hersteller oder man hat den Fehler gefunden.

[walterschmitt]

Habe doch ein Demoprogramm an den Hersteller geschickt.
Das Programm war ein Fenster mit nichts anderem als nur dieser Komponente.
Bei mir Crash, beim Hersteller läuft es.
Glaube langsam es liegt an meiner Windows-Installation.
Habe auch den Sourcecode und kenne die verantwortliche Codezeile.
Bei mir zeigt die Speicheradresse der Variablen auf $FFFFFFFF930FFA58 und damit ins Nirvana.
Sollte eigentlich $00000000930FFA58 sein.

[jaenicke]

Kann es sein, dass da irgendwelche Casts im Spiel sind?

Wird die Variable schon falsch geschrieben? An der Stelle helfen Datenhaltepunkte, wenn der Wert zuerst richtig ist und später falsch. Denn dann kannst du auf die Variable nach dem korrekten Setzen einen Datenhaltepunkt setzen und dann schauen, wo der geändert wird.

[jziersch]

Zitat von walterschmitt:

Bei mir zeigt die Speicheradresse der Variablen auf $FFFFFFFF930FFA58 und damit ins Nirvana.Sollte eigentlich $00000000930FFA58 sein.

Überprüfe mal alle Variablen die an die Komponente übergeben werden. Kein Zeiger darf Cardinal sein, sondern stattdessen ein IntPtr. In altem 32bit code finden sich manchmal noch Cardinals.
Der Crash ist dann abhängig vom System, Speicheraufbau etc.

[himitsu]

Zitat:

... IntPtr ... Cardinals ...

Oder gar Integer (31 Bit) mit Prüfungen auf < 0, drum ist IMAGE_FILE_LARGE_ADDRESS_ AWARE nicht standardmäßig aktiv.

UIntPtr
IntPtr
NativeUInt
NativeInt

und allgemein überall die richtigen Typen, wie z.B. LPARAM, WPARAM und LRESULT für SendMessage/PostMessage, anstatt Integer/Cardinal usw.
oder andersrum z.B. HRESULT statt Integer/Cardinal/Sonstwar für das aus GetLastError und Co.



Hier sieht es eher so aus, als wenn signed 32 Bit-Integer-Zeiger (nicht unsigned Cardinal) an einen 64 Bit-Integer übergeben/gecastet wird.
$9xxxxxxx hat das höchste Bit gesetzt, drum wird/bleibt das negaitv, also es werden auch alle 32 höheren Bits negativ.

In Bezug auf einen Integer->Int64 ist es vollkommen korrekt, dass es ab $800000000 zu $FFFFFFFF800000000 wird.

[peterbelow]

Zitat von walterschmitt:

Habe doch ein Demoprogramm an den Hersteller geschickt.
Das Programm war ein Fenster mit nichts anderem als nur dieser Komponente.
Bei mir Crash, beim Hersteller läuft es.
Glaube langsam es liegt an meiner Windows-Installation.
Habe auch den Sourcecode und kenne die verantwortliche Codezeile.
Bei mir zeigt die Speicheradresse der Variablen auf $FFFFFFFF930FFA58 und damit ins Nirvana.
Sollte eigentlich $00000000930FFA58 sein.

Das sieht so aus als wenn ein 32-bit signed integer auf ein 64 bit signed integer (oder pointer) gecasted wird...