Programm-Absturz seit Delphi 11.2

[walterschmitt]

In Delphi 11.1 konnte ich mein Programm als 32bit und 64bit Programm compilieren und ausführen.

Mit Delphi 11.2 ist es möglich beide zu kompilieren, jedoch läuft nur die 32bit Variante normal.
Das 64bit-Programm zeigt nach dem Start nicht einmal das Hauptformular an, sondern stürzt ab mit dieser Fehlermeldung :

Error : EOutofResources in ......
Stream konnte nicht gespeichert werden.

????

[freimatz]

Sorry wenns böse klingt ...
Ich denke an "Immer wenn Gras über eine Sache gewachsen ist, kommt ein Kamel und frisst es wieder ab.". Das Kamel ist hier Delphi 11.2.
Irgendwas stimmt nicht an Eurem Code. Zufälligerweise ging es immer gut, nun halt nicht mehr weil im Speicher da jetzt halt was anderes liegt.
Vorschläge
Alle Hints und Warnings einschalten und beheben.
FixInsight benutzen und: Alle Hints und Warnings beheben.

[Uwe Raabe]

Um es anders zu formulieren: Bei mir kommt der Fehler nicht. Das kann natürlich daran liegen, dass mein Code was anderes macht als dein Code.

[himitsu]

https://quality.embarcadero.com/brow...ofResources%22
liefert auch nichts Passendes

Wie wäre es mit einer detailierteren Fehlerbeschreibung/Fehlersuche?

Strg+C im Fehlerdialog oder im LogFenster des Debuggers
und dann Strg+V als Text hier in ein [QUOTE]...[/QUOTE],
für eine "vollständige" richtiggeschriebene Fehlermeldung.

Und dann im Debugger siehe Call-Stack, um rauszubekommen, von wo dieser Fehler eigentlich her kommt.

[KodeZwerg]

Zitat:

Zitat von walterschmitt (Beitrag 1512908)

In Delphi 11.1 konnte ich mein Programm als 32bit und 64bit Programm compilieren und ausführen.

Mit Delphi 11.2 ist es möglich beide zu kompilieren, jedoch läuft nur die 32bit Variante normal.
Das 64bit-Programm zeigt nach dem Start nicht einmal das Hauptformular an, sondern stürzt ab mit dieser Fehlermeldung :

Error : EOutofResources in ......
Stream konnte nicht gespeichert werden.

????

Das kam bei nicht vor, selbst uralte Quelltexte laufen einwandfrei.

[himitsu]

Ich schaffe es nur immer wieder mitten beim Schreiben von Quellcode die IDE komplett einschlafen zu lassen,
so das der Taskmanager 0% und "inaktiv" dazu sagt.

[walterschmitt]

Zitat:

Sorry wenns böse klingt ...
Ich denke an "Immer wenn Gras über eine Sache gewachsen ist, kommt ein Kamel und frisst es wieder ab.". Das Kamel ist hier Delphi 11.2.
Irgendwas stimmt nicht an Eurem Code. Zufälligerweise ging es immer gut, nun halt nicht mehr weil im Speicher da jetzt halt was anderes liegt.
Vorschläge
Alle Hints und Warnings einschalten und beheben.

Ist bei mir immer eingeschaltet.
Und mein Programm erzeugt keinerlei Hints und Warnungen.

Hab aber die Ursache gefunden : Es ist eine externe Komponente.
Bin mit dem Anbieter im Gespräch.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1512913)

Ich schaffe es nur immer wieder mitten beim Schreiben von Quellcode die IDE komplett einschlafen zu lassen,
so das der Taskmanager 0% und "inaktiv" dazu sagt.

Vielleicht schreibst du einfach nur so langweiligen Code, dass die IDE dabei einschläft. :duck:

[himitsu]

Eigentlich lasse ich mich durch die Syntax quälen, bzw. quäle das ErrorInsight/CodeInsigth mit brutalen eigentlich normalen Dingen.

z.B. https://quality.embarcadero.com/browse/RSP-39558 und mehrfach verschachtelte managed Records :oops:

[Poelser]

[QUOTE=walterschmitt;1512944]

Zitat:

Hab aber die Ursache gefunden : Es ist eine externe Komponente.
Bin mit dem Anbieter im Gespräch.

Wäre nett, wenn erzählen würdest welche es ist, und was dort das Problem ist. Das könnte auch anderen helfen, die auch auf diese Mine treffen.

[rwalper]

Bei uns gibt es das gleiche Problem, unter 11.1 läuft die 32-bit und 64-bit-Anwendung einwandfrei, unter 11.2 crashed nur die 64-bit-App beim Laden der DFM des Hauptformulars, allerdings mit einer anderen Fehlermeldung (ClientHandle nicht gültig oder so) Wir haben alles auf 11.1 zurückgedreht, wir haben aktuell leider keine Zeit, uns damit aufzuhalten.

Wir nutzen DevXpress-Ribbon und -Backstagepanel im Hauptformular und hatten diese Komponenten im Verdacht. Ich habe nun eine leere MDI-Applikation erstellt mit eben diesem Ribbon und dem Backstagepanel und hatte gehofft, dass sich der Fehler nachvollziehen lässt, leider nein:(

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

[Uwe Raabe]

Zitat:

Zitat von rwalper (Beitrag 1512981)

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

Wenn kein Bug gemeldet wird, kann auch kein Bug behoben werden. Weder von Embarcadero noch von DevExpress. Man kann ja auch nicht völlig ausschließen, dass der Fehler vielleicht in eurem eigenen Code liegt. Dann nutzt warten rein gar nichts.

[jaenicke]

Zitat:

Zitat von rwalper (Beitrag 1512981)

allerdings mit einer anderen Fehlermeldung (ClientHandle nicht gültig oder so) Wir haben alles auf 11.1 zurückgedreht, wir haben aktuell leider keine Zeit, uns damit aufzuhalten.

Es wäre ja nun kein großer Zeitaufwand, zumindest den Stacktrace des Fehlers zu dokumentieren und den Fehler zu melden. Wenn dabei nichts herauskommt, kann man ja immer noch schauen, ob und wann man mehr Zeit investieren kann.

Und vielleicht hat ja jemand hier im Forum ein ähnliches Problem oder könnte helfen, so dass auch hier der Stacktrace helfen würde.

[atari1040]

Delphi hat sehr viel gemeinsam mit dem HSV in der 2. Liga. Es gibt immer eine Hand voll Leute, die den großen Mist der gebaut wurde noch verteidigen. Die Qualität von Delphi 11 Alexandria ist und bleibt eine Katastrophe.

[jaenicke]

Zitat:

Zitat von atari1040 (Beitrag 1512984)

Die Qualität von Delphi 11 Alexandria ist und bleibt eine Katastrophe.

Heute werden Bugs aber in vielen Fällen viel schneller als früher behoben. Da hat sich im Vergleich zu früher wirklich viel getan.

Was wirklich gar nicht geht, ist die Qualität der Syntaxergänzung. Die verwendet man nun einmal sehr oft und wenn die nicht geht, wie es seit der Umstellung auf LSP leider oft ist, ist das nicht haltbar.

Wenn ich mir allerdings die Anzahl der Bugmeldungen zu Delphi 11 anschaue, dann kann die Qualität für viele gar nicht so schlimm sein.

[atari1040]

Zitat:

Zitat von jaenicke (Beitrag 1512985)

...

Wenn ich mir allerdings die Anzahl der Bugmeldungen zu Delphi 11 anschaue, dann kann die Qualität für viele gar nicht so schlimm sein.

Vielleicht liegt es daran, dass wir unsere Zeit effektiver nutzen müssen, als ständig Bug Meldungen für Delphi zu erstellen. Man benutzt es einfach nur noch dann, wenn man unbedingt muss. Es gibt ja kaum noch eine IDE, mit der man weniger produktiv ist als mit Delphi. Das Gegenteil ist der Fall.
Ich habe da noch ein Beispiel. Wenn ich ein altes Projekt pflegen muss und es in Delphi 11 lade, friert mir die IDE ein. Ich habe lange gesucht, warum das so ist. Von den vielen verwendeten Komponenten war eine nicht installiert. Vor Delphi 11 hat mir die IDE noch gemeldet, dass ein Package nicht geladen werden konnte. Jetzt friert die IDE einfach ein. Da wird doch seit Monaten überhaupt nicht drauf eingegangen.

[Uwe Raabe]

Zitat:

Zitat von atari1040 (Beitrag 1512984)

Es gibt immer eine Hand voll Leute, die den großen Mist der gebaut wurde noch verteidigen.

Verteidigen ist wohl nicht das richtige Wort. Mithelfen es zu verbessern kommt dem schon eher nahe. Im Gegensatz zum HSV (na ja, bis auf einen marginalen Personenkreis) geht das bei Delphi schon, wenn man es möchte.

Ich arbeite gezwungenermaßen mit unterschiedlichen Delphi-Versionen für verschiedene Projekte und muss da immer wieder feststellen, wie mir so manches Feature der neueren Versionen plötzlich fehlt. Natürlich nerven mich auch die bestehenden Bugs, in vielen Fällen wohl auch schon eine Weile länger als so manchen hier. Nur, lamentieren und/oder abwarten tragen rein gar nichts zur Lösung des Problems bei.

Dabei bleibt in diesem Fall immer noch die Frage, ob das Problem wirklich in Delphi selbst liegt, oder ob vielleicht eine sinnvolle und wünschenswerte Änderung (z.B. ASLR) in der letzten Version lediglich die Schwachstellen in anderem Code sichtbar macht.

[atari1040]

Zitat:

Zitat von Uwe Raabe (Beitrag 1512987)

Dabei bleibt in diesem Fall immer noch die Frage, ob das Problem wirklich in Delphi selbst liegt, oder ob vielleicht eine sinnvolle und wünschenswerte Änderung (z.B. ASLR) in der letzten Version lediglich die Schwachstellen in anderem Code sichtbar macht.

Wenn Delphi Schwachstellen aufdeckt kann ich gut damit leben. Wenn eine IDE einfriert und ich nicht mal eine Fehlermeldung bekomme kann ich weniger gut damit leben. Antworten wie "passiert bei mir nicht" sind da immer weniger hilfreich. Es passiert uns ja auch, dass Anwender einen Fehler melden, den wir nicht nachvollziehen können. Da antwortet man am besten nicht, dass es auf dem Entwickler-PC nicht passiert sondern geht mit dem Anwender, der bestimmt zu Recht den Fehler meldet, in die Analyse. Delphi zu verbessern? Ich glaube das ist so unmöglich wie das der HSV Deutscher Meister wird.

[Uwe Raabe]

Zitat:

Zitat von atari1040 (Beitrag 1512988)

Es passiert uns ja auch, dass Anwender einen Fehler melden, den wir nicht nachvollziehen können.

Immerhin meldet der Anwender den Fehler! Was wäre, wenn der Anwender statt dessen euer Programm (oder die neue Version) nicht nutzt und stattdessen in öffentlichen Foren über die miserable Qualität wettert und das Programm als totalen Mist bezeichnet?

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.

[atari1040]

Zitat:

Zitat von Uwe Raabe (Beitrag 1512989)

...

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.

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1512985)

Wenn ich mir allerdings die Anzahl der Bugmeldungen zu Delphi 11 anschaue, dann kann die Qualität für viele gar nicht so schlimm sein.

Joar,
* das nichtgehende CodeInsight und CodeCompletion
* gleichnamige Inlinevariablen beim Debuggen
* eine IDE die koplett hängen bleibt ... ist voll fießt ... früher krachte es einfach weg und man wusste das war's und nun bekommt man hoffnungslos die Hoffnung es könnte sich wieder fangen

* aber sonst melde ich grade eher Fehler/Features, die mich schon länger nerven

Jetzt, wo ALLES gut läuft, darf man doch endlich mal fragen, ob sich diesbezüglich endlich mal was ändern lässt? :duck:
https://quality.embarcadero.com/browse/RSP-20885
https://quality.embarcadero.com/browse/RSP-39676
https://quality.embarcadero.com/browse/RSP-39558

[Fritzew]

Die Problem mit 64 Bit kommen meiner Meinung nach von
der jetzt default eingeschalteten Option für ASL im Linker

Das kann man relativ einfach überprüfen: ASLR abschalten in den Linker-Einstellungen.
Zur Sicherheit beide Optionen.

Dann hilft nur Debugger und schauen wo eventuell Typen nicht passen

[walterschmitt]

Zitat:

Die Problem mit 64 Bit kommen meiner Meinung nach von
der jetzt default eingeschalteten Option für ASL im Linker

Das kann man relativ einfach überprüfen: ASLR abschalten in den Linker-Einstellungen.
Zur Sicherheit beide Optionen.

Habe ich jetzt gemacht.
Läuft jetzt.

[Uwe Raabe]

Zitat:

Zitat von walterschmitt (Beitrag 1512993)

Habe ich jetzt gemacht.
Läuft jetzt.

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.

[Uwe Raabe]

Zitat:

Zitat von atari1040 (Beitrag 1512990)

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:

Zitat von rwalper (Beitrag 1512981)

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:

Zitat von atari1040 (Beitrag 1512990)

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:

Zitat von atari1040 (Beitrag 1512990)

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:

Zitat von walterschmitt (Beitrag 1512998)

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:

Zitat von walterschmitt (Beitrag 1512998)

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:

Zitat von walterschmitt (Beitrag 1513006)

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. :stupid:

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. :angle:

[peterbelow]

Zitat:

Zitat von walterschmitt (Beitrag 1513006)

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...

[walterschmitt]

Nachdem ich die Stelle im Quellcode der Komponente genau identifizieren konnte, wo bei mir der Fehler auftrat und welche Werte die Variablen haben, hat der Komponentenhersteller die Sache gefixt.
Es war ein Pointerproblem.
Jetzt läuft es.

[Sherlock]

:dp:

*Mike drop*

Sherlock

[rwalper]

Von mir auch ein kurzes Update: das Problem ist nun auch bei uns gefixed.
Der Fehler lag in einer sehr alten Komponente, wo ein Pointer über Longint gecastet wurde (alle Casts von Integer() und Cardinal() haben wir ja gefunden, aber leider nicht nach Longint() gesucht).
Mit abgeschaltetem ASLR ist das Programm wieder gestart, wenn auch mit anderen Fehlern. Nach dem temporären Entfernen der Komponente hat alles wieder funktioniert.
Vielen Dank für eure Hilfe.:)