Frage bezüglich Debugger

LazarusRocks · Beitrag von **LazarusRocks** » Sa 10. Apr 2010, 11:49

Hallo,
ich wollte kürzlich einen Bug in der Lazarus IDE suchen.
Nun habe ich aber ein Problem beim debuggen.

Und zwar gehe ich wie folgt vor:
1.) öffnen des Projektes \ide\lazarus.lpi.
2.) F9
3.) die zweite Lazarus Instanz erscheint, aber bleibt an mehreren Stellen stehen, obwohl ich da keine Break-Points hingemacht habe.
Es werden auch keine Infos über den Grund des Unterbruches angezeigt.

z.B. hier:

function SortGridRows(Item1, Item2 : pointer) : integer;
begin
Result:=SysUtils.CompareText(TOIPropertyGridRow(Item1).Name,
TOIPropertyGridRow(Item2).Name);
end;

Ich muss dann x-mal F9 drücken damit es weiter geht.
Muss man da irgendwo etwas in den Settings ändern ?
Was passiert z.B. beim obigen Beispiel wenn der Pointer nicht initialisiert ist oder nicht vom Type TOIPropertyGridRow ?

Danke

martin_frb · Beitrag von **martin_frb** » Sa 10. Apr 2010, 12:43

Hm, merkwürdig...

Zuerst mal: Hast du die IDE (+ LCL, etc) mit Debug Symbolen neu kompiliert? (wie groß ist deine Lazarus.exe > 100MB?).
Mit welchen anderen Optionen?

Also welche Version von GDB? Bei mir laufen 6.8.3 und 7.0 (Vista)

Es kann schon seien, das es zu Exceptions kommt, aber dann sollte es Dir sagen welche (zb stream read error, wenn die LFM Fehler hat). Und dann kann man wählen die zu ignorieren.

Und was sind die Meldungen im "Menu/View/debug/Debug output" Window?

LazarusRocks · Beitrag von **LazarusRocks** » So 11. Apr 2010, 06:57

Hallo Martin,

ja, meine Lazarus.exe ist ca 100MByte gross.

Das erste Mal wo der Debugger stoppt ist hier.

Code: Alles auswählen

constructor TMainIDEBar.Create(TheOwner: TComponent);
begin
  inherited Create(TheOwner);
 
  ControlDocker:=TLazControlDocker.Create(Self);
  ControlDocker.Name:='MainIDEBar';
  {$IFDEF EnableIDEDocking}
  ControlDocker.Manager:=LazarusIDE.DockingManager;  <---hier
  {$ENDIF}
end;

Ich habe dann wie du vorgeschlagen hast das "Call Stack" Fenster angeschaut. Guter Tip! Da steht <error reading variable>.

Code: Alles auswählen

#0 TMAINIDEBAR__CREATE(0xd61c0, 0x1, <error reading variable>) at mainbar.pas:433
#1 TAPPLICATION__CREATEFORM(<incomplete type>, void, <error reading variable>) at .\include\application.inc:2053
#2 TMAINIDE__CREATE(0xd61c0, 0xb49030, <error reading variable>) at main.pp:1293
#3 main at lazarus.pp:102

Der zweite Unterbruch ist wie bereits gesagt bei:

Code: Alles auswählen

function SortGridRows(Item1, Item2 : pointer) : integer;
begin
  Result:=SysUtils.CompareText(TOIPropertyGridRow(Item1).Name,
                               TOIPropertyGridRow(Item2).Name);
end;

Das Stack-Trace dazu sieht so aus:

Code: Alles auswählen

#0 SORTGRIDROWS(0x949b7d8, 0x949afb8) at objectinspector.pp:803
#1 CLASSES_QUICKSORT$PPOINTERLIST$LONGINT$LONGINT$TLISTSORTCOMPARE at :0
#2 CLASSES_TFPLIST_$__SORT$TLISTSORTCOMPARE at :0
#3 TOICUSTOMPROPERTYGRID__BUILDPROPERTYLIST(false, <error reading variable>) at objectinspector.pp:1620
#4 TOICUSTOMPROPERTYGRID__SETSELECTION(0x8ac9018, <error reading variable>) at objectinspector.pp:1154
#5 TOBJECTINSPECTORDLG__REFRESHSELECTION(<error reading variable>) at objectinspector.pp:4170
#6 TOBJECTINSPECTORDLG__SETSELECTION(0x8abde08, <error reading variable>) at objectinspector.pp:4147
#7 TCUSTOMFORMEDITOR__SETSELECTION(0x948fdf8, <error reading variable>) at customformeditor.pp:931
#8 TMAINIDE__ONCONTROLSELECTIONCHANGED(0x8b10930, false, <error reading variable>) at main.pp:12945
#9 TCONTROLSELECTION__DOCHANGE(false, <error reading variable>) at E:\lazarus\designer\controlselection.pp:1917
#10 TCONTROLSELECTION__ENDUPDATE(<error reading variable>) at E:\lazarus\designer\controlselection.pp:962
#11 TCONTROLSELECTION__ASSIGNPERSISTENT(0x9517c78, <error reading variable>) at E:\lazarus\designer\controlselection.pp:2042
#12 TMAINIDE__DOSHOWDESIGNERFORMOFCURRENTSRC(<error reading variable>) at main.pp:12142
#13 TMAINIDE__DONEWFILE(0x8ada5c8, 0x948c620 'unit1.pas', 0x0, [NFISPARTOFPROJECT, NFOPENINEDITOR, NFCREATEDEFAULTSRC], 0x0, <error reading variable>) at main.pp:7894
#14 TLAZIDEINTERFACE__DONEWEDITORFILE(0x8ada5c8, 0x948c620 'unit1.pas', 0x0, [NFISPARTOFPROJECT, NFOPENINEDITOR, NFCREATEDEFAULTSRC], <error reading variable>) at lazideintf.pas:399
#15 TPROJECTAPPLICATIONDESCRIPTOR__CREATESTARTFILES(0x9ab4398, <error reading variable>) at project.pp:6039
#16 TMAINIDE__DONEWPROJECT(0x8accb98, <error reading variable>) at main.pp:9373
#17 TMAINIDE__SETUPSTARTPROJECT(<error reading variable>) at main.pp:2128
#18 TMAINIDE__STARTIDE(<error reading variable>) at main.pp:1373
#19 main at lazarus.pp:105

Scotty · Beitrag von **Scotty** » So 11. Apr 2010, 10:20

Hast du die IDE (+ LCL, etc) mit Debug Symbolen neu kompiliert?

Wo kann man das denn ausschalten? Ein -Xs unter erweiterte Compilereinstellungen hilft nicht.

martin_frb · Beitrag von **martin_frb** » So 11. Apr 2010, 13:09

Wo hab ich den call stack gesagt?

Und was sind die Meldungen im "Menu/View/debug/Debug output" Window?
==> Debug output

Auffällig ist das der erste Stop mit {$IFDEF EnableIDEDocking} zu tun hat => Keine Ahnung ob das von vielen Lazarus Entwicklern genutzt wird...

LazarusRocks · Beitrag von **LazarusRocks** » Mi 14. Apr 2010, 20:57

Sorry, du hast natürlich nicht den Call-Stack gemeint.

Also, ich habe nun zwei Dinge getan:

1.) das ganze nochmals compiliert ohne den Docking-Teil.
Die führt mich aber gerade noch zu einer anderen Frage: Im Lauf der Jahr ist ja ziemlich viel in das Projekt eingeflossen.
Ich nehme an, das hat es auch Sachen drin, die wieder mal ausgeputzt werden müssten.
Hat da jemand noch den Überblick und wer entscheidet ?

2.) Nun hält Lazarus bei SortGrid immer noch an. Da wollte ich nun ins "Menu/View/debug/Debug output" rein, aber Lazarus geht dann auf 100% CPU Load, reagiert nicht mehr und ich muss es leider mit dem TaskManager killen.

Gruss Sämi

martin_frb · Beitrag von **martin_frb** » Mi 14. Apr 2010, 22:39

Ah,ja, das debug output Fenster hat da wohl nen bug => öffne es bevor du anfängst zu debuggen. Das geht immer, und dann solltest du ne menge zeug sehen.

Interessant sind die Zeilen (10 bis 20) direkt wo er anhält. GDB sollte dort ausgeben warum er stopped.
Allerdings könnte es schwierig sein die zu kriegen => wenn die blauen punkte geladen werden (nach dem anhalten), gehen 100te von Zeilen da rein...

Apropos GDB => du hattest noch nicht gesagt welche Version du hast.
Altere Versionen machen da gern Probleme.Von MinGW Version 7 laden.

Bezüglich "ausgeputzten" => hast du irgendwas im Auge?
Normalerweise laufen die Bemühungen, dahin das so was gar nicht erst reinkommt. Spezielle Suchaktionen gibt es eher nicht. Aber wenn jemand über was stolpert....

LazarusRocks · Beitrag von **LazarusRocks** » Mo 19. Apr 2010, 19:04

Ich habe mir einen neuen Daily-Snapshot installiert und nun hält der Debugger nicht mehr an.
Das ist jetzt ok.

Noch zu deiner Frage bezüglich Debugger Version. Ich habe im Verzeichnis lazarus\mingw\bin die Datei gdb.exe mit Version 7.0.

Wenn ich die IDE mit -dEnableIDEDocking compiliere, dann kann ich das Source-Code Fenster schön an die IDE-MainBar an-docken.
Sobald ich dann aber Lazarus beende gibt es eine AV und anschliessend noch eine "Division by Zero".

Soll ich das im BugTracker erfassen ?

martin_frb · Beitrag von **martin_frb** » Mo 19. Apr 2010, 19:50

Zunächst mal: gut zu wissen das der Debugger nun läuft.

Ich werde unabhängig von nem Bug Report mal danach schauen => allerdings wird es wahrscheinlich eine Weile dauern bevor ich dazu komme... Und es ist fraglich ob es vollständig repariert wird.
Vermutlich gibt es auch Probleme, wenn du das Projekt schließt, oder neu öffnest, während Dinge am SourceEditor gedockt sind. Das ist vermutlich kaum zu reparieren...

Du kannst die IDE mit -dSingleSrcWindow kompilieren. Das wird vermutlich den Absturz beseitigen. Allerdings kannst du dann die neuen Multi-window Funktionen nicht nutzen (source-editor Kontext Menü: move/copy to new window)

Es gibt eine Package "Manual Docker " => die SVN Version läuft mit den neuen Features.

martin_frb · Beitrag von **martin_frb** » Mi 21. Apr 2010, 11:37

LazarusRocks hat geschrieben:Ich habe mir einen neuen Daily-Snapshot installiert und nun hält der Debugger nicht mehr an.
Wenn ich die IDE mit -dEnableIDEDocking compiliere, dann kann ich das Source-Code Fenster schön an die IDE-MainBar an-docken.
Sobald ich dann aber Lazarus beende gibt es eine AV und anschliessend noch eine "Division by Zero".

Welche Version von Lazarus hast du denn *zuvor* benutzt?

Ich habe das gerade mal mit 0.9.28 probiert.
1) Editor an Main gedockt => Das Main Menu ist weg
2) Die Exception beim schließen gab es schon in 0.9.28

Das heißt die Exception hat nix mit den neuen Multi-Window zu tun, und -dSingleSrcWindow wird auch nix helfen.

Den Absturz beim Schließen hab ich repariert (r24784).

LazarusRocks · Beitrag von **LazarusRocks** » Do 22. Apr 2010, 07:07

Hallo Martin,

zu 1)
Wenn ich den SourceEditor and das MainMenu andocke, dann sieht es auf den ersten Blick nur so aus als ob das Main Menu verschwindet.
Wenn du aber genauer hinsiehst, dann erkennst du sicher dass das beim Andocken nicht MainBar.height+SourceEditor.height genommen wird, sondern dass das SourceEditor-Fenster in die Höhe der MainBar eingepasst wird und somit die Mainbar "verdrängt". Mit der Maus und dem "Splitter" zwischen MainBar und SourceEditor kann man dann die Sache auf die gewünschte Grösse zurecht ziehen.

zu 2)
Danke, dein Fix hat das Problem behoben.

Ich glaube so nahe am Ziel "Lazarus und Docking" war die IDE noch nie.

Nochmals vielen Dank!

martin_frb · Beitrag von **martin_frb** » Do 22. Apr 2010, 11:44

Den Splitter hab ich gesehen => das Menü ist bei mir trotzdem weg (die Buttons und Komponenten-Leiste sind da)

Die IDE ist weder näher noch ferner am Docking....

EnableIDEDocking (to the best of my knowlege) war vor langer Zeit ein Versuch. Aber EnbleIDEDocking ist von der Art der Implementierung mehr oder weniger komplett falsch => und wird schon seit langem nicht mehr gepflegt oder erweitert.

Der derzeitig evtl und am meisten Versprechende Ansatz zu Docking, ist in Examples "EasyDockingMgr". Allerdings noch nicht in die IDE integriert....

LazarusRocks · Beitrag von **LazarusRocks** » Fr 23. Apr 2010, 23:05

EnableIDEDocking (to the best of my knowlege) war vor langer Zeit ein Versuch. Aber EnbleIDEDocking ist von der Art der Implementierung mehr oder weniger komplett falsch => und wird schon seit langem nicht mehr gepflegt oder erweitert.

Genau aus diesem Grund war meine Frage in diesem Thread, ob auch mal etwas altes aus dem Lazarus-Projekt rausfliegt und wer darüber entscheidet.

Vielleicht noch zur Erklärung wieso ich so verzweifelt auf eine IDE mit Docking warte:

Das Problem wurde bereits von jemand anderem im BugTracker erfasst und ist äusserst lästig.
Ich hatte gehofft, das Problem mittels "Docking" zu entschärfen.
see http://bugs.freepascal.org/view.php?id=14854" onclick="window.open(this.href);return false;

Also wenn ich mittels Ctrl-F aus der VirtualBox(winxp) rausgehe zurück ins Ubuntu und anschliessend wieder zurück in die Virtualbox dann sind alle IDE-Fenster wieder and den falschen Orten und haben eine falsche Grösse. Ich muss dann die MainBar, den ObjektInspector ,den SourceEditor und das MessageView wieder einzeln positionieren und die Grösse anpassen.

Nun aber noch zu jetztigen -dEnableIDEDocking Docking-Variante:
Du hast ja freundlicherweise den hier beschriebenen "Division by zero Crash" gefixt.
Nun habe ich aber gleich den nächsten "Division by zero" Crash gefunden.

Und zwar so:

1.) zuerst Messages Window and SourceEditor andocken. ( funktioniert )
2.) dann SourceEditor an MainBar andocken. Ergibt einen Crash!

Habe die Sache untersucht:

Diese Exception wird ausgelöst:

Code: Alles auswählen

if Control.Parent<>nil then
    RaiseGDBException('TCustomAnchoredDockManager.InsertControl Control.Parent<>nil');

Code: Alles auswählen

#0 RAISEGDBEXCEPTION(0xcf1e60 'TCustomAnchoredDockManager.InsertControl Control.Parent<>nil') at lclproc.pas:1505
#1 TCUSTOMANCHOREDDOCKMANAGER__DOCKCONTROL(0x972bde8, ALBOTTOM, 0x8b82350, <error reading variable>) at ldocktree.pas:2134
#2 TCUSTOMLAZCONTROLDOCKER__SHOWDOCKINGEDITOR(<error reading variable>) at ldockctrl.pas:703
#3 TSOURCENOTEBOOK__DOCKINGCLICKED(0x130b88, <error reading variable>) at sourceeditor.pp:6257
#4 TIDEMENUITEM__MENUITEMCLICK(0x8cd1220, <error reading variable>) at menuintf.pas:538
#5 TIDEMENUCOMMAND__MENUITEMCLICK(0x8cd1220, <error reading variable>) at menuintf.pas:1549
#6 TMENUITEM__CLICK(<error reading variable>) at .\include\menuitem.inc:75
#7 TMENUITEM__DOCLICKED(void, <error reading variable>) at .\include\menuitem.inc:269
#8 SYSTEM_TOBJECT_$__DISPATCH$formal at :0
#9 TMENUITEM__GETPARENTCOMPONENT(<error reading variable>) at .\include\menuitem.inc:258

Leider verstehe ich das Ganze aber nicht.

martin_frb · Beitrag von **martin_frb** » Fr 23. Apr 2010, 23:54

LazarusRocks hat geschrieben:EnableIDEDocking (to the best of my knowlege) war vor langer Zeit ein Versuch. Aber EnbleIDEDocking ist von der Art der Implementierung mehr oder weniger komplett falsch => und wird schon seit langem nicht mehr gepflegt oder erweitert.
Genau aus diesem Grund war meine Frage in diesem Thread, ob auch mal etwas altes aus dem Lazarus-Projekt rausfliegt und wer darüber entscheidet.

Zwischen rausfliegen und suspendierter (oder allergeringster Priorität) Maintenance ist immer noch ein Unterschied.
Ich weiß es nicht, vermute aber, dass das rausfliegt, wenn richtiges Docking drin ist.

Zum Thema was und warum: Wiki/Faq => Da sind die Gründe

LazarusRocks hat geschrieben: Vielleicht noch zur Erklärung wieso ich so verzweifelt auf eine IDE mit Docking warte:

Das Problem wurde bereits von jemand anderem im BugTracker erfasst und ist äusserst lästig.
Ich hatte gehofft, das Problem mittels "Docking" zu entschärfen.
see http://bugs.freepascal.org/view.php?id=14854" onclick="window.open(this.href);return false;

Es gibt eine Menge verschiedene Dinge die für verschiedene Gruppen lästig oder wichtig oder ... sind.
Aber ich verstehe schon was Du meinst...

Hast du mal versucht in Eviroment/options/enviroment/windows => Die Einstellung für die Fenster von "Position wiederherstellen" auf "benutzerdefiniert oder gespeicherte pos" zu ändern ?

Dann kannst du die Fenster schlissen und neu öffnen (oder Projekt/Session speichern, Lazaurs neu starten), und sie sollten an der richtigen Position sein

LazarusRocks hat geschrieben: Nun aber noch zu jetztigen -dEnableIDEDocking Docking-Variante:
Du hast ja freundlicherweise den hier beschriebenen "Division by zero Crash" gefixt.
Nun habe ich aber gleich den nächsten "Division by zero" Crash gefunden.

Division by Zero, ist nur eine Hilfe um die Exception für GDB anzupassen (Da GDB sonst FPC Exceptions nicht mag)

LazarusRocks hat geschrieben: Und zwar so:

1.) zuerst Messages Window and SourceEditor andocken. ( funktioniert )
2.) dann SourceEditor an MainBar andocken. Ergibt einen Crash!

Habe die Sache untersucht:

Diese Exception wird ausgelöst:

Code: Alles auswählen

if Control.Parent<>nil then
    RaiseGDBException('TCustomAnchoredDockManager.InsertControl Control.Parent<>nil');

Code: Alles auswählen

#0 RAISEGDBEXCEPTION(0xcf1e60 'TCustomAnchoredDockManager.InsertControl Control.Parent<>nil') at lclproc.pas:1505
#1 TCUSTOMANCHOREDDOCKMANAGER__DOCKCONTROL(0x972bde8, ALBOTTOM, 0x8b82350, <error reading variable>) at ldocktree.pas:2134
#2 TCUSTOMLAZCONTROLDOCKER__SHOWDOCKINGEDITOR(<error reading variable>) at ldockctrl.pas:703
#3 TSOURCENOTEBOOK__DOCKINGCLICKED(0x130b88, <error reading variable>) at sourceeditor.pp:6257
#4 TIDEMENUITEM__MENUITEMCLICK(0x8cd1220, <error reading variable>) at menuintf.pas:538
#5 TIDEMENUCOMMAND__MENUITEMCLICK(0x8cd1220, <error reading variable>) at menuintf.pas:1549
#6 TMENUITEM__CLICK(<error reading variable>) at .\include\menuitem.inc:75
#7 TMENUITEM__DOCLICKED(void, <error reading variable>) at .\include\menuitem.inc:269
#8 SYSTEM_TOBJECT_$__DISPATCH$formal at :0
#9 TMENUITEM__GETPARENTCOMPONENT(<error reading variable>) at .\include\menuitem.inc:258

Leider verstehe ich das Ganze aber nicht.

Keine Ahnung, und im Moment auch weder Zeit noch Lust (noch Priorität)

Das Problem ist, das niemand mehr den IdeDocking Code testet.
Keine Ahnung durch welche Veränderung von Lazarus der Fehler entstanden ist.

Du kannst probieren die IDE mit
-dOldAutoSize
-dSingleSrcWindow

oder sogar beiden zu kompilieren. Ob es was hilft weiß ich aber nicht.

Martin

Deutsches Lazarusforum

Frage bezüglich Debugger

Frage bezüglich Debugger

Re: Frage bezüglich Debugger

Re: Frage bezüglich Debugger

Re: Frage bezüglich Debugger

Re: Frage bezüglich Debugger

Re: Frage bezüglich Debugger

Re: Frage bezüglich Debugger

Re: Frage bezüglich Debugger

Re: Frage bezüglich Debugger

Re: Frage bezüglich Debugger

Re: Frage bezüglich Debugger

Re: Frage bezüglich Debugger

Re: Frage bezüglich Debugger

Re: Frage bezüglich Debugger