Delphi XE stürzt beim Speichern ab

[himitsu]

Beim Speichern einer Unit landet Delphi in einer Endlosschleife und stürzt dann ab.

Vermutlich liegt das irgendwie an einer der eigenen Komponenten, aber das ließ sich nicht genau feststellen.
(bei Dreien auf der Form passiert nichts, wenn ich eine davon entferne)

Im eigenen Code knallt es nicht.
Und es ist total nervig, wenn man beim Debuggen oder durch den Code diese Unit (unbemerkt) öffnet und dann später beim Speichern alles verreckt und vieles dann nicht gespeichert wird.

Das Problem:

• ein Bugfix für XE kann man vergessen
• seit bestimmt über einem halben/dreiviertel Jahr wurde immer mal wieder nach der Fehlerursache gesucht.
• die IDE zu Debuggen war nicht so leicht, vorallem da der Stacktrace im Delphi nach 10.000 Einträgen einfach so aufhört und man den Anfang/Ursprung nur schwer fand
• Aktion auslösen und Pause drücken war auch nicht so toll, da die 10.000 im Bruchteil einer Sekunde voll waren
• und man nach jeder Mal komplett neu anfangen durfte, da die IDE ja total abkackt (schön, wenn sich da BPLs/DLLs öfters mal verschieben und in passender Haltepunkt so etwas schwer vorhersehbar war)
• es passiert irgendwo in delphicoreide150.bpl (leider ohne die geringsten Debuginfos und man sieht garnichts)
• ...

Vielleicht entdeckt/weiß jemand wo es da knallt und an was sich Delphi hier verschlucken könnte. (welcher Teil einer/unserer Komponente dort behandelt wird)

Ach ja, das Speichern selber ist nicht der Grund, denn Alt+F12 geht problemlos, wobei ja die Form-Instanz serialisiert/gespeichert und freigegeben wird, um in den Text-Modus zu schalten.
Und wenn die Unit zwar offen ist, aber sich in der DFM-Ansicht befindet, dann kann man problemlos auf Speichern/AllesSpeichern klicken.

Es knallt immer nur, wenn die DFM geladen ist (egal ob sie angezeigt wird, man sich den Quellcode ansieht, oder sich in einer anderen Unit befindet)

Es ist einfach nur noch nervig, wenn immer mal wieder (manchmal 'nen Monat lang nicht und dann wieder alle paar Minuten, weil man irgendwas fertigmachen will und dann im entscheidenden Moment einfach nicht dran denkt)
Schön auch, daß hier alles abraucht und nicht nur eine "konnte nicht Speichern"-Exception kommt. -> Meldung: Stacküberlauf, dann Klick auf OK und weg ist alles.



Nach langem Kampf fand ich nun den vollen Stacktrace heraus. (die letzten 1-3 Punkte unterscheiden sich immer mal)

Code:

:5008ac13 GetMethodProp + $3F
:210849e1 TCompInfo.GetEventValue + $1
:21b90782 ; C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\delphicoreide150.bpl
:21b90796 ; C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\delphicoreide150.bpl
...
:21b90796 ; C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\delphicoreide150.bpl
:21b90791 ; C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\delphicoreide150.bpl
:21b9084a delphicoreide150.@Delphimodule@TPascalCodeMgrModHandler@ValidateMethods$qqrv + 0x72
:21b8ff39 delphicoreide150.@Delphimodule@TPascalCodeMgrModHandler@Update$qqro + 0x91
:208af5fd coreide150.@Sourcemodule@TCodeISourceModule@Update$qqro + 0x7d
:208adba6 coreide150.@Sourcemodule@TSourceModule@Save$qqroo + 0x8a
:20a7939e ; C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\coreide150.bpl
:0041d716 ; C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\bds.exe
:500aec38 TBasicActionLink.Execute + $18
:5027db93 TControl.Perform + $27
:50282161 TWinControl.IsControlMouseMsg + $B1
:5032381d TToolBar.WndProc + $249
:50281ed3 TWinControl.MainWndProc + $2F
:500afa66 StdWndProc + $16
:75b862fa ; C:\Windows\SysWOW64\user32.dll
:75b86d3a user32.GetThreadDesktop + 0xd7
:75b877c4 ; C:\Windows\SysWOW64\user32.dll
:75b8788a user32.DispatchMessageW + 0xf
:50358afc TApplication.ProcessMessage + $F8

Bei manuellen Debuggen (vor dem Knall) kam ich, unter anderem, auf diesen Stacktrace, wo der Code ständig wieder vorbei kommt:

Code:

    1 :771d17e8 ntdll.RtlUTF8ToUnicodeN + 0xc
    2 :75ca583b ; C:\Windows\SysWOW64\KERNELBASE.dll
    3 :75ca59d3 ; C:\Windows\SysWOW64\KERNELBASE.dll
    4 :75ca0463 KERNELBASE.MultiByteToWideChar + 0x43
    5 :500415f4 UnicodeFromLocaleChars + $18
    6 :50040d0a Utf8ToUnicode + $32
    7 :500412db UTF8ToUnicodeString + $47
    8 :50088844 GetPropName + $24
    9 :21084afd TCompInfo.InitSubList + $99
   10 :21084ba2 TCompInfo.GetSubInfoCount + $12
   11 :21b90796 ; C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\delphicoreide150.bpl
   12 :21b90796 ; C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\delphicoreide150.bpl
  ...
 9999 :21b90796 ; C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\delphicoreide150.bpl
10000 :21b90796 ; C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\delphicoreide150.bpl

Kurz vor dem rekursiven Aufruf/Sprung taucht ein TCompInfo.GetSubInfo+$96 auf.

Der Sprung selber (siehe Stacktrace, was da so oft vorkommt) ist bei Offset $000B0791 in der delphicoreide150.bpl zu finden.

Code:

21B90782 59               pop ecx
21B90783 84C0             test al,al
21B90785 741C             jz $21b907a3
21B90787 8B4508           mov eax,[ebp+$08]
21B9078A 50               push eax
21B9078B 8B55F4           mov edx,[ebp-$0c]
21B9078E 8B45F8           mov eax,[ebp-$08]
21B90791 E88AFFFFFF       call $21b90720  <<<<<<<

So, und nun bin ich mit meinem Latein am Ende und komm einfach nicht weiter, bzw. weiß nicht was/wo ich noch suchen könnte.
Die Komponenten sind recht groß und über die Jahrzehnte gewachsen durch Ausbau/Auskommentierung von Code/Komponenten (was halt so alles wegzumachen ging) fand ich auch nichts raus.
Auf anderen Formularen gibt es keine Probleme ... nur auf dem Einem, mit wirklich viel drauf. (PgDAC, FastReport, List&Label und was sonst noch alles zum Erstellen/Verwalten der Reports nötig war)

Auf eine neuere/andere Delphi-Version lässt sich das Projekt auch noch nicht portieren, nur um mal zu sehen ob der Fehler von selber wegginge. (zuviele Abhängigkeiten und Fremdkomponenten)



Vielen Dank für's Angucken/Mitdenken
Frank

[stahli]

Ich hatte mit ähnlichen Problemen zu tun, als ich an meinem ersten Databindingframework gearbeitet hatte.

Das hing aber immer mit dem Erzeugen eines Packages zusammen, wenn Komponenten daraus gerade in einem geladenen und sichtbaren Formular enthalten waren. Die Komponenten wurden dem Formular dann sozusagen unterm Arsch weggezogen und mein Framework kam dann nicht mehr klar....

Beim Speichern kann das ja nicht der Grund sein.

Hast Du das Package der Komponenten in der Projektgruppe als abhängig eingebunden?
Vielleicht bringt es dann etwas, das Package aus der Projektgruppe zu entfernen.

[himitsu]

Die betreffende Form liegt in einer DLL, welche mit Packages kompiliert wurde.
Die Komponenten kommen aus aus mehreren Packages.

An den Packages und deren Units wird aber nichts geändert, also wird/sollte auch auch kein Package entladen werden.



Aber ja, diese Probleme kennen wir auch. In einigen DesigntimePackages wird irgendwo etwas nicht wieder richtig deregistriert und wenn man die neu kompipiliert, dann knallt es oftmals.
Genauso das Packagekompilieren, während eine Form offen ist, oder bestimmte abhänige Packages in der IDE geladen sind.

[Uwe Raabe]

Das ist natürlich alles nur Fischen im Trüben, aber wenn eine Komponente auf andere Komponenten verweist, wie z.B. ein DataSource auf ein DataSet , und man vergisst die FreeNotification , dann kommt es zu unvorhersehbaren Fehlern, wenn die Referenz vielleicht nicht mehr gültig ist.