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