Nach Update auf Delphi12 startet compiliertes Prog nicht mehr. Fehler bei LoadResStri

[himitsu]

Zitat:

Zitat von dummzeuch (Beitrag 1537999)

Es scheint irgendwas im Initialisierungs-Code der Procedure zu sein.

Eigentlich sollte dort im Beginn garnicht viel drin sein,
außer dass ein billiger Bytepuffer (8 KB) auf den Stack gepusht wird, bzw. eigentlich sogar einfach nur der Stackpointer um diese 8 KB verschoben wird.
OK, und vorher der Zeiger-Wert für den Parameter und den Zeiger des Result auch noch auf den Stack, aber alles nichts Wildes.

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1538036)

Zitat:

Zitat von dummzeuch (Beitrag 1537999)

Es scheint irgendwas im Initialisierungs-Code der Procedure zu sein.

Eigentlich sollte dort im Beginn garnicht viel drin sein,
außer dass ein billiger Bytepuffer (8 KB) auf den Stack gepusht wird, bzw. eigentlich sogar einfach nur der Stackpointer um diese 8 KB verschoben wird.
OK, und vorher der Zeiger-Wert für den Parameter und den Zeiger des Result auch noch auf den Stack, aber alles nichts Wildes.

Eben: Eigentlich. Aber wenn es da knallt, muss das von irgendwas dort ausgelöst werden.

@Bernau: Selbst wenn man nicht selbst versteht, was da genau passiert, hilft es vielleicht, einen Screenshot des CPU-Fensters vor der Anweisung, die die Exception auslöst, hier zu posten.

Kas Ob.'s Vermutung, dass da der Stack kaputt ist, könnte man damit auch überprüfen.

Ohne weitere Informationen raten wir hier nur rum.

[MichaelT]

Ist das Projekt dynamisch gelinkt?

Zitat:

Zitat von bernau (Beitrag 1538032)

Zitat:

Zitat von Uwe Raabe (Beitrag 1538013)

Anhand der Stelle mit dem Fehler würde ich auch eine defekte Resource in Betracht ziehen.

Daran habe ich auch schon gedacht. Ich verwende keine selbst erstellten Ressourcen.

Habe die Ressourcen-Dateien *.rc, *.res und *.dres gelöscht. Die werden neu Aufgebaut. Fehler immer noch da.

Gibt es noch irgendwelche Ressourcen-Dateien, die ich vielleicht übersehen haben könnte?

[Kas Ob.]

Zitat:

Zitat von dummzeuch (Beitrag 1538039)

@Bernau: Selbst wenn man nicht selbst versteht, was da genau passiert, hilft es vielleicht, einen Screenshot des CPU-Fensters vor der Anweisung, die die Exception auslöst, hier zu posten.

Kas Ob.'s Vermutung, dass da der Stack kaputt ist, könnte man damit auch überprüfen.

Ohne weitere Informationen raten wir hier nur rum.

Well this will not useful at all after the exception because the EIP already pointing to inaccessible address.

But there is a way, and bernau words "Ist ja nicht so mein Ding." made me stop explaining how to catch this, though it is not hard nor late to learn, so here we go :
1) put breakpoint on this line "if Assigned(P) and Assigned(Pointer(P^)) then"
2) run the application until it stop on the above breakpoint
3) open the CPU View and watch the stack pointer and its content like this in the screenshot
Anhang 56940
We don't care about anything else, just the two values at the blue arrow, what are we watching for, these values on that breakpoint must stay the same all the time and on every execution.
4) hit RUN on the debugger or F9 key, the debugger will stop again on that break point, and the blue arrow (the stack pointer) should be pointing to the same values each time, on side note all the vlaue above also should be not changed in this case, it might change in different case, but that is different talk for different place.
5) keep hiting F9 until you see different values, this means the last initialization section had corrupted the stack already, we stop here , without closing the debugger.
6) from the local variables for this thread, you willse the value inside P, it should be in hex, something like $xxxxxxxx.
7) on my IDE XE8, there is
IDE Main Menu -> Search -> Go to Address , open it and write the P address, and don't forget the $ , the place for this option might be different in newer IDEs, i have no idea.
8) you will land on the initialization that caused the stack to corrupt, investigate there.

[dummzeuch]

Zitat:

Zitat von Kas Ob. (Beitrag 1538043)

Zitat:

Zitat von dummzeuch (Beitrag 1538039)

@Bernau: Selbst wenn man nicht selbst versteht, was da genau passiert, hilft es vielleicht, einen Screenshot des CPU-Fensters vor der Anweisung, die die Exception auslöst, hier zu posten.

Well this will not useful at all after the exception because the EIP already pointing to inaccessible address.

Yes, that's why I wrote "*vor* der Anweisung, die die Exception auslöst". ;-)

[Kas Ob.]

Zitat:

Zitat von dummzeuch (Beitrag 1538045)

Zitat:

Zitat von Kas Ob. (Beitrag 1538043)

Zitat:

Zitat von dummzeuch (Beitrag 1538039)

@Bernau: Selbst wenn man nicht selbst versteht, was da genau passiert, hilft es vielleicht, einen Screenshot des CPU-Fensters vor der Anweisung, die die Exception auslöst, hier zu posten.

Well this will not useful at all after the exception because the EIP already pointing to inaccessible address.

Yes, that's why I wrote "*vor* der Anweisung, die die Exception auslöst". ;-)

Sorry, my bad.

[Kas Ob.]

Zitat:

Zitat von Kas Ob. (Beitrag 1538043)

1) put breakpoint on this line "if Assigned(P) and Assigned(Pointer(P^)) then"
.

correction the breakpoint should be at "P := Table^[I].Init;"

[jaenicke]

Kann es sein, dass du irgendwelche Delphiunits kopiert und modifiziert eingebunden hast?

Ich verstehe das doch richtig:
Andere Projekte gehen?

Dann würde ich ein frisches Projekt nehmen, an der gleichen Stelle speichern und die Units wieder einfügen. Zuerst kannst du ja die Soap.XSBuiltIns mal einzeln in die uses packen.

Wenn es dann mit allen Units geht, liegt es an den Projekteinstellungen.

Wenn nicht, muss es an einer Unit liegen. Dann würde ich die der Reihe nach rauswerfen bis es geht. Dauert etwas, weil es ja jeweils kompilieren muss, aber sollte zum Ergebnis führen. Wenn wirklich Speicher kaputt ist, kann es natürlich sein, dass das auch nicht reicht, aber dann müsste man eh konkret schauen, warum es an der Stelle knallt, sprich den Speicher prüfen.

[bernau]

Fehler gefunden. Puh.

Schuld war eine Unit "gnuGettext.pas", welche irgendwie beim Umzug auf Delphi 12 und bei der Anpassung der Quelltexte in eine bestehende Unit "reingerutscht" ist.

Ich habe keine Funktion dieser Unit genutzt. Weis der Geier weshalb die auf einmal in der Uses einer Unit auftaucht.

Alleine macht "gnuGettext.pas" keine Probleme. Allerdings in Kombination mit "Soap.XSBuiltIns" knallt es.

Konnte ich dann einfach nachvollziehen. Neues Projekt, beide Units in die Uses des Projektquelltextes rein und starten. Knallt sofort.

Habe in meiner alten Delphi11 Installation nachgeschaut. Dort ist diese Unit nicht eingebunden. Also Entwarnung. Es hat nicht wirklich etwas mit dem Umstieg von Delphi 11 auf Delphi 12 zu tun. Das Problem saß vor dem Bildschirm.

Ich will die Unit gnuGettext nicht schlecht reden. Meine Version ist aber von 2010 und ich weis nicht, ob es dafür Updates gibt und wofür die überhaupt gebraucht wird. Habe diese nie genutzt.

Danke noch mal für eure Tipps.

[bernau]

Zitat:

Zitat von Kas Ob. (Beitrag 1538035)

Zitat:

Zitat von Kas Ob. (Beitrag 1538007)

Hi,

Zitat:

Zitat von bernau (Beitrag 1537995)

Hat jemand eine Idee, wo ich weiter suchen kann?

Look in every "initialization" section being called before this one, most likely the exact unit before "Soap.XSBuiltIns", this one is innocent and the error somewhere earlier.

Keep going back, i mean the empty initialization contains a simple ret instruction, which will work always, but some unit initialization before that did ruin you stack.
And to be exact, that exception you are receiving is hardware raised by a ret instruction while the stack value is $ce93d58d instead of the address pointing to right after "TProc(P)();"

You're right. Finally i dived in everey TProc(P) and looked what happend in the initialization-section "and" all "class constructors" wich also where initialized in the InitUnits. Because of about 900 steps, i missed the initialization-part of "gnugettext".