Code Browsing bringt seit Rio Update 3 die IDE ständig zum Absturz

[philipp.hofmann]

Hi,

in einem recht großen Projekt von mir, stürzt die IDE seit Rio Update 3 ständig ab, wenn ich auf eine Methode klicke um zur Methodendeklaration zu kommen (Code Browsing). Ich habe auch einen Bug im Emba-System erstellt, aber vielleicht hat ja jemand einen Tipp. In kleineren Projekten kann ich es nicht so einfach nachstellen. Es gibt leider keinen Fehlerreport, sondern dauert 5 Sekunden und dann ist die IDE weg.

Grüße, Philipp

[himitsu]

Du kannst die IDE im Debugger (einer weiteren IDE) starten oder via Package (BPL) z.B. Eurekalog oder Dergleichen in der IDE laden,
dann bekommst du bei Auftritt eines Fehlers die entsprechende Stelle angezeigt.

in IDE:
Start > Process laden > $(BDS)\bin\bds.exe
oder
Start > Mit Process verbinden > und dort eine vorher gestartete zweite Delphi-Instanz auswählen (bds.exe ... die ohne disableten Verbinden-Knopf)

in Package:
dort z.B. Eurekalog (oder was Ähnliches) einbinden und dieses Package in der IDE installieren (laden).

Delphi ist mit Delphi kompiliert und verwendet die selben Units der RTL/VCL und vor allem alles der Unit SysUtils.

[hoika]

Hallo,

Zitat:

um zur Methodendeklaration zu kommen

Du meinst, du bis gerade an einer Stelle, wo die Methode aufgerufen wird und willst zu Ihrer Deklaration.
Oder bist Du im implementation-Teil dieser Methode?

Im Fall 1, ist die Methode in der gleichen Unit oder in einer anderen.
Wenn Sie in einer anderen ist, ist diese andere Unit in der IDE offen?

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1454280)

Du kannst die IDE im Debugger (einer weiteren IDE) starten oder via Package (BPL) z.B. Eurekalog oder Dergleichen in der IDE laden,
dann bekommst du bei Auftritt eines Fehlers die entsprechende Stelle angezeigt.

Das ist ist in der Regel aber kaum hilfreich. Man kann evtl. einen Call Stack bekommen, mit dem man was anfangen kann, z.B. kann man manchmal erkennen, ob es wirklich die IDE selbst ist oder ein Plugin, aber auch das ist alles andere als einfach.

[philipp.hofmann]

a) Ich habe es mit "Start > Process laden > $(BDS)\bin\bds.ex" ausprobiert und dort hat die gleiche Aktion funktioniert.
b) Es ist egal, ob die ausgerufene Methode in der gleichen Klasse, einer anderen ungeöffneten Klasse oder einer anderen geöffneten Klasse ist.
c) Ich will vom Methodenaufruf zur Implementierung der aufgerufenen Methode springen.
d) Seit ich (a) durchgeführt habe, geht es wieder, zumindest stürzt die IDE nicht mehr ab. Davor führte es reproduzierbar zu dem Fehler.
-> mal weiter beobachten

[himitsu]

Joar, das kenn ich auch zu oft, auch bei eigenen Programmen.
Im Debugger gestartet geht es plötzlich ... wie soll man da dann den Fehler finden? :lol:

Sich erst im Fehlerfall mit dem Debugger dranzuhängen, dafür wartet es hier dann ja leider nicht.
Sonst könnte man das Programm auch erst starten, auf den "Fehler" warten, am Besten z.B. bis es hängt oder wo ein Dialog angezeigt wird,
dann Debugger anhängen, auf Pause gehen, in den Stacktrace gucken und eventuell noch paar Mal F7, falls im Stack noch nichts Hilfreiches zu finden ist.

Zitat:

Zitat von dummzeuch (Beitrag 1454290)

Das ist ist in der Regel aber kaum hilfreich.

Achso? Wenn man sonst absolut keinerlei Hinweis hat, warum etwas spurlos verschwindet, dann hilft es natürlich garnichts wenigstens erstmal rauszufinden wo etwas passiert, was man dann eventuell auch dem Support sagen könnte. :stupid:

[hoika]

Hallo,
im Debugger, also unter Beobachtung reagiert die IDE anders.

Das ist ja wie in der Quantenphysik, wo die verschränkten Teilchen nur funktionieren, wenn man nicht hinseht ;)
Die lassen sich auch nicht unter den Rock schauen ;).

[philipp.hofmann]

Nicht ganz. Seid der Debugger gelaufen ist, stürzt die IDE auch im Normalbetrieb beim Code Browsing nicht mehr ab. Was auch immer dies bewirkt hat.

Jetzt ist es nur noch so, dass nicht immer an die richtige Stelle gesprungen wird, sondern das richtige File aufgeht, man aber in einer Zeile zu weit vorne ankommt, dafür aber in Spalte 4096 landet. Dies ist aber deutlich besser verkraftbar als der Crash, schickt man eben ein Search hinterher. Davor konnte ich es x-mal hintereinander mit dem Crash reproduzieren und jetzt kann ich genau dies x-mal hintereinander reproduzieren.

[stahli]

Dann würde ich doch mal eine Repair-Installation versuchen (wenn der Installer sowas anbietet) oder halt eine Neuinstallation.

[philipp.hofmann]

Das Thema ist schon länger bekannt und schon in früheren Rio-Versionen aufgetreten: RSP-24626.
Da hilft dann eine Repair-Installation auch nicht wirklich und ich muss auf Emba warten. Habe aber mal für den Issue gevotet.

[himitsu]

Eine bessere Fehlerbehandlung in der IDE würde dann so aussehen,

Beispiel von grade eben, da hier durch ein Package für unser Programm zufällig Eurekalog in der IDE drin ist.

Code:

[004280B5]{bds.exe} Sanctuary.ProductTimer..TProductTimer + $431
[00420C8C]{bds.exe} Sanctuary.Util..{Sanctuary.Util}TSortedList<System.string,System.string> (Line 13, "Sanctuary.Util.pas" + 0) + $2870
[20A2BD10]{coreide150.bpl} DebuggerMgr.TThreadEvent.Send (Line 732, "DebuggerMgr.pas" + 2) + $8
[20A2BF78]{coreide150.bpl} DebuggerMgr.TProcessNotifierWrapper.CurrentThreadChanged (Line 848, "DebuggerMgr.pas" + 0) + $0
[20674BC5]{dbkdebugide150.bpl} Debug.TDebugger.DoThreadChange (Line 10795, "Debug.pas" + 11) + $8
[2066F23A]{dbkdebugide150.bpl} Debug.TProcess.SetCurrentThread (Line 8353, "Debug.pas" + 9) + $6
[206702F4]{dbkdebugide150.bpl} Debug.TProcess.IOTAProcess_SetCurrentThread (Line 9031, "Debug.pas" + 3) + $4
[205C643E]{coreproide150.bpl} ThrdStat.TThreadStatus.MakeCurrentClick (Line 446, "ThrdStat.pas" + 16) + $8
[5027E4F5]{vcl150.bpl} Controls.TControl.DblClick (Line 7195, "Controls.pas" + 1) + $14
[5027E670]{vcl150.bpl} Controls.TControl.WMLButtonDblClk (Line 7238, "Controls.pas" + 4) + $C
[5027DF6C]{vcl150.bpl} Controls.TControl.WndProc (Line 7074, "Controls.pas" + 91) + $6
[50282110]{vcl150.bpl} Controls.TWinControl.IsControlMouseMsg (Line 9616, "Controls.pas" + 9) + $25
[50282830]{vcl150.bpl} Controls.TWinControl.WndProc (Line 9831, "Controls.pas" + 144) + $6
[5031B8AA]{vcl150.bpl} ComCtrls.TCustomListView.WndProc (Line 18705, "ComCtrls.pas" + 22) + $4
[50281ED0]{vcl150.bpl} Controls.TWinControl.MainWndProc (Line 9552, "Controls.pas" + 3) + $6
[500AFA64]{rtl150.bpl} Classes.StdWndProc (Line 13491, "Classes.pas" + 8) + $0
[50358AF7]{vcl150.bpl} Forms.TApplication.ProcessMessage (Line 9760, "Forms.pas" + 23) + $1
[50358B3A]{vcl150.bpl} Forms.TApplication.HandleMessage (Line 9790, "Forms.pas" + 1) + $4
[50358E65]{vcl150.bpl} Forms.TApplication.Run (Line 9927, "Forms.pas" + 26) + $3

Aber da hier bei deinem Fehler leider garkeine Fehlermeldung kommt, ist leider bezweifelbar, dass dann dieser Fehlerdialog mit soeinem Stacktrace angezeigt würde.

Bei mir war der Debugger verreckt, kurz nachdem ich das Programm angehalten hatte und wo ich auf den Mainthread switchen wollte. Danach mußte die IDE leider abgeschossen und neu gestartet werden. :(
k.A. was am Ende das Sanctuary will, aber der Mist ist eh überall, aber die wichtigen Stellen (SetCurrentThread > CurrentThreadChanged > TThreadEvent.Send) sind dennoch gut zu sehen.
Und wenn man, wie hier, garnichts weiß, dann ist das Wenige schon viel.