Fixed. Please test.

Mattias

Is it me, or what happened to the IDE (Win7/64, 32 bit exe's)?

Can somebody confirm/fix these issues:

- Help on IDE Options leads to *Compiler* options.

- The config dialog, shown on start with an invalid config, expects an fpc *executable*, but browses only for a *directory*, so that \fpc.exe has to be added manually.

- The Call Stack only flashes shortly, then the list is cleared (when the next instruction is displayed in the editor). (gdb 6.8 32 bit)

- Rebuild IDE doesn't honor "with packages" off, always builds *with* packages.

Have nice holidays :-)

DoDi

I removed the obsolete option.

Mattias

Do you mean the "Help" button?
What page in the dialog is selected?

Mattias

Hans-Peter Diettrich wrote

- The Call Stack only flashes shortly, then the list is cleared (when the next instruction is displayed in the editor). (gdb 6.8 32 bit)

I have only Vista 32 bit.
So if this is a win7 only issue, then i do not know about it.

I am not sure what you mean by the description?
The call-stack is supposed to fill when the debugger stops. If executiopn continues (run F9 / Step F8,.F7) it is cleared until the execution stops again.

Ah! I thought that it was "Debugger" options, but I cannot reproduce the above glitch any more :-(

BTW: when "Help" is the active page, I get an overview of the IDE Options pages. The entry for Project Options is a bit misplaced there, but a list of *all* option dialogs (including project and compiler options) would be nice. Eventually with sections and instructions, how to invoke the according dialogs...

DoDi

> - Rebuild IDE doesn't honor "with packages" off, always builds *with* > packages. I removed the obsolete option.

How can I rebuild the IDE *without* packages, or with different sets of packages, for testing purposes?

It were sufficient to have the Lazarus.lpi (or a new one) for that purpose, provided that it behaves like the rebuilt IDE.

Background: I'm playing around with the IDEDockMaster (and more), and I have to determine frequently whether my changes affect the IDE in general, or only the IDE with a DockMaster or other package.

Hint: In former times Lazarus.lpi did not install any packages.

DoDi

Fine, thanks :-)

DoDi

This happens automatically. When the packages have not changed, only the IDE is rebuild. Just like any project.

or with different sets of packages, for testing purposes?

a) the pcp parameter
b) the install packages dialog allows save/load of sets c) see below

It were sufficient to have the Lazarus.lpi (or a new one) for that purpose, provided that it behaves like the rebuilt IDE.

The lazarus.lpi only allows to run and debug the IDE. The set of installed packages are stored in the primary config directory.

You can save lazarus.lpi as lazarus2.lpi and enable the building in the compiler options. Then you can install any packages you like.

Mattias

Do you mean
http://wiki.lazarus.freepascal.org/Lazarus_IDE

I doubt if it very useful, sometimes I think it is misleading.

Eventually with sections and instructions, how to invoke the according dialogs...

+1
That's why I added such a note to several of these pages. Please help to complete such hints.

Mattias

Not good, and worse, I can only guess, since it doesn't happen on my PC

The time taken is normal, it's the time it takes to load the line-info (blue dots) from gdb.

Anyway, first we need to establish if gdb returns anything (or even if the IDE asks.

Please have a look at the content of the "debug output" window.

When the stack window is open (and the power button enabled !), and the execution stops (breakpoint, end of step) you should see something like (it helps to have watches and other windows closed, and to turn the power off in the "history" window)

<-stack-info-depth>
^done,depth="42"
(gdb)
<-stack-list-arguments 1 0 9>
^done,stack-args=[frame={level="0",args=[{name="SENDER",value="0x1ca9d0"},{name="this",value="<error reading
variable>"}]},frame={level="1",args=[{name="this",value="0x1ca9d0"}]},frame={level="2",args=[]},frame={level="3",args=[]},frame={level="4",args=[]},frame={level="5",args=[]},frame={level="6",args=[{name="this",value="0x41d2934"},{name="MESSAGE",value="0"}]},frame={level="7",args=[{name="this",value="0x1ca9d0"},{name="THEMESSAGE",value="{MSG = 66567, WPARAM = 0, LPARAM = 0, RESULT = 0, WPARAMLO = 0, WPARAMHI = 0, LPARAMLO = 0, LPARAMHI = 0, RESULTLO = 0, RESULTHI = 0}"}]},frame={level="8",args=[{name="this",value="0x1ca9d0"},{name="MESSAGE",value="{MSG = 66567, WPARAM = 0, LPARAM = 0, RESULT = 0, WPARAMLO = 0, WPARAMHI = 0, LPARAMLO = 0, LPARAMHI = 0, RESULTLO = 0, RESULTHI = 0}"}]},frame={level="9",args=[{name="TARGET",value="0x1ca9d0"},{name="AMESSAGE",value="0"}]}] (gdb)
<-stack-list-frames 0 9>
^done,stack=[frame={level="0",addr="0x00428a59",func="TFORM1__BUTTON4CLICK",file="unit1.pas",fullname="C:/data/lazarus/bug1/unit1.pas",line="131"},frame={level="1",addr="0x00500ef1",func="CLICK",file="include/control.inc",fullname="C:/lazarus_latest/lcl/include/control.inc",line="2286"},frame={level="2",addr="0x00543df3",func="STDCTRLS_TBUTTONCONTROL_$__CLICK"},frame={level="3",addr="0x005444e6",func="STDCTRLS_TCUSTOMBUTTON_$__CLICK"},frame={level="4",addr="0x00544b91",func="STDCTRLS_TBUTTON_$__CLICK"},frame={level="5",addr="0x00543cae",func="STDCTRLS_TBUTTONCONTROL_$__WMDEFAULTCLICKED$TMESSAGE"},frame={level="6",addr="0x0040b1e6",func="DISPATCH",file="../inc/objpas.inc",fullname="C:/FPC/SVN/trunc/rtl/win32/../inc/objpas.inc",line="592"},frame={level="7",addr="0x004ffce3",func="WNDPROC",file="include/control.inc",fullname="C:/lazarus_latest/lcl/include/control.inc",line="1683"},frame={level="8",addr="0x004f3628",func="WNDPROC",file="include/wincontrol.inc",fullname="C:/lazarus_latest/lcl/include/wincontrol.inc",line="5241"},frame={level="9",addr="0x005665de",func="DELIVERMESSAGE",file="lclmessageglue.pas",fullname="C:/lazarus_latest/lcl/lclmessageglue.pas",line="111"}] (gdb)

If you see something like this, the try close and open the stack window,

Check if you see at least the commands being issued: <-stack-info-depth>
<-stack-list-arguments 1 0 9>
<-stack-list-frames 0 9>

There may be more, and they may be for smaller number ranges too.

If you get this, then maybe it is an issue with the listview not displaying the updates....
Could even be an uncaught exception, and the list view be left with a "BeginUpdate" that is never finished (though they all should have try finally blocks...)

Check if you select "copy all", if you get the stack frames...

Lazarus 0.9.31 rev. 29341 (snapshot) works as expected, same system, same debugger. Trunk worked, too, until I updated recently. [BTW: trunk version says "SVN revision: unknown"]

I am not sure what you mean by the description? The call-stack is supposed to fill when the debugger stops.

Rigth, but now it appears to be always empty :-(

If executiopn continues (run F9 / Step F8,.F7) it is cleared until the execution stops again.

The effect is best seen with F7, when a step into a subroutine takes some time until the begin of the subroutine is focused in the editor, in a different file. Here the Call Stack list is filled with entries, just after pressing F7, and is cleared when the new position is shown in the editor. The ListView title (column) bar also disappears for a short time, and when it reappears[1] the list is empty.

Using F8, where the focus only moves to the next line in the same file, the CallStack appears to remain almost empty.

[1] The flashing title bar may be related to a RecreateWnd (or the like), after which the widget is not populated again. (TListView bug?)

DoDi

P.S.: this message failed to ship in the first attempt.

The same here

Lazarus 0.9.31 r30913 FPC 2.4.2 i386-win32-win32/win64

Luiz

Win 7 ? 32 bit?

See my other mail for trying to collect some info on it

unscribe me...

WindowsXP 32bit

GDB from 2.4.2 fcp installer

See my other mail for trying to collect some info on it

It seems gdb is working:

*stopped,reason="breakpoint-hit",bkptno="17",thread-id="1",frame={addr="0x00423f6e",func="TFORMDESIGN__RLREPORT1BEFOREPRINT",args=[{name="SENDER",value="0xb67c0"},{name="PRINTIT",value="true"},{name="this",value="0xb60c0"}],file="UnitDesign.pas",fullname="D:/repositories/fortes4lazarus/demos/biolife/UnitDesign.pas",line="110"} (gdb)
<-stack-info-depth>
^done,depth="27"
(gdb)
<-stack-list-arguments 1 0 9>
^done,stack-args=[frame={level="0",args=[{name="SENDER",value="0xb67c0"},{name="PRINTIT",value="true"},{name="this",value="0xb60c0"}]},frame={level="1",args=[{name="this",value="0xb67c0"}]},frame={level="2",args=[{name="this",value="0xb67c0"}]},frame={level="3",args=[{name="this",value="0xb67c0"}]},frame={level="4",args=[{name="DEST",value="0x0"},{name="this",value="0xb67c0"}]},frame={level="5",args=[{name="SENDER",value="0xb5a00"},{name="this",value="0xb55a0"}]},frame={level="6",args=[{name="this",value="0xb5a00"}]},frame={level="7",args=[{name="this",value="0xb5a00"}]},frame={level="8",args=[{name="this",value="0xb5a00"}]},frame={level="9",args=[{name="this",value="0xb5a00"}]}] (gdb)
<-stack-list-frames 0 9>
^done,stack=[frame={level="0",addr="0x00423f6e",func="TFORMDESIGN__RLREPORT1BEFOREPRINT",file="UnitDesign.pas",fullname="D:/repositories/fortes4lazarus/demos/biolife/UnitDesign.pas",line="110"},frame={level="1",addr="0x00591738",func="TRLCUSTOMCONTROL__DOBEFOREPRINT",file="rlreport.pas",fullname="D:/repositories/fortes4lazarus/rlreport.pas",line="6873"},frame={level="2",addr="0x005a4f17",func="TRLCUSTOMREPORT__INTERNALPREPARE",file="rlreport.pas",fullname="D:/repositories/fortes4lazarus/rlreport.pas",line="13370"},frame={level="3",addr="0x005a662a",func="TRLCUSTOMREPORT__PREPARENEEDED",file="rlreport.pas",fullname="D:/repositories/fortes4lazarus/rlreport.pas",line="13955"},frame={level="4",addr="0x005a5121",func="TRLCUSTOMREPORT__PREVIEW",file="rlreport.pas",fullname="D:/repositories/fortes4lazarus/rlreport.pas",line="13454"},frame={level="5",addr="0x00423cc6",func="TMAINFORM__PREVIEWBUTTONCLICK",file="Main.pas",fullname="D:/repositories/fortes4lazarus/demos/biolife/Main.pas",line="38"},frame={level="6",addr="0x004dd2d3",func="TCONTROL__CLICK",file="./include/control.inc",fullname="D:/repositories/lazarus/lcl/include/control.inc",line="2286"},frame={level="7",addr="0x005284ff",func="TBUTTONCONTROL__CLICK",file="./include/buttoncontrol.inc",fullname="D:/repositories/lazarus/lcl/include/buttoncontrol.inc",line="62"},frame={level="8",addr="0x005289cf",func="TCUSTOMBUTTON__CLICK",file="./include/buttons.inc",fullname="D:/repositories/lazarus/lcl/include/buttons.inc",line="174"},frame={level="9",addr="0x00528ef1",func="TBUTTON__CLICK",file="./include/buttons.inc",fullname="D:/repositories/lazarus/lcl/include/buttons.inc",line="339"}] (gdb)
<-thread-info>
^error,msg="Undefined mi command: thread-info (missing implementation)" (gdb)
<-thread-select -1>
&"Thread ID -1 not known.\n"
^error,msg="Thread ID -1 not known."
(gdb)
<-thread-select 1>
^done,new-thread-id="1",frame={level="0",addr="0x00423f6e",func="TFORMDESIGN__RLREPORT1BEFOREPRINT",args=[{name="SENDER",value="0xb67c0"},{name="PRINTIT",value="true"},{name="this",value="0xb60c0"}],file="UnitDesign.pas",fullname="D:/repositories/fortes4lazarus/demos/biolife/UnitDesign.pas",line="110"} (gdb)
<-stack-list-arguments 1 0 0>
^done,stack-args=[frame={level="0",args=[{name="SENDER",value="0xb67c0"},{name="PRINTIT",value="true"},{name="this",value="0xb60c0"}]}] (gdb)
<-stack-list-locals 1>
^done,locals=[{name="SENDER",value="0xb67c0"}]
(gdb)

I see the above. See other mail

I dont get those

Luiz

When the stack window is open (and the power button enabled !), and the execution stops (breakpoint, end of step) you should see something like (it helps to have watches and other windows closed, and to turn the power off in the "history" window)

Bingo! The History causes the error.

When I open the History window and turn it off, the Call Stack works as it should.

It would be nice to have the History turned off by default, as before. Where should I look for that?

DoDi

Unfortunately I still need to implement such an option.

IMHO, it would be best to have it fixed....

I found something in Luiz's mail. the gdb did not understand the "thread info" cmd.
While I need to fix this, using a later version of gdb may help too...

The callstack issue is actually caused by the thread window.. even with snapshots off, if the thread window is open, the error occurs. Snapshots, just force the threads to be loaded, even if the window is closed

As for "snapshots being on by default" I see not fault in this. As for "no global/persistent config for snapshots 9and/or other debug windows), on the list, but not highest priority

I added some fixes. (to make it work with threads/history)

Please try

Any reason why not taking the newer GDB from Lazarus installer? (gdb 7.2)

Of course you do not need to, older gdb are supported (or should be)

Perhaps in TSnapshotManager.Create, where FActive:=True seems to cause
the wrong behaviour? The History Power button toggles just this property.

DoDi

Avoid extra download. I already have fpc one. From lazarus i get only the source.

Anyway, it's was working fine until recently.

As a general rule i use the provided by fpc stable release that is supposed to work with the respective compiler version

Of course you do not need to, older gdb are supported (or should be)

In my opinion it should support at least the gdb provided by the supported compiler version.

BTW: next Lazarus release will support fpc 2.4.2?

Luiz

Works here. Thanks

Luiz

Above change works for me. I don't know about other windows, which also may block the Call Stack when opened. For now it's sufficient that *never opened* windows don't block debugging.

DoDi

Well, they weren't supposed to.

It isn't about the windows, it's about the data behind. Since the debugger now knows about threads, the callstack must ensure to get the stack for the current thread (quite obvious). Previously, that was hidden in gdb, the thread was never changed, so the callstack returned was automatically correct. Now the callstack passes in an extra argument. And that got messed up.

Anyway it's fixed now...

--------
And yes, I have plans to add a persistent config to switch the history off by default.
I do thing that in most cases it is good to have it running, it does not hurt, and it runs on idle time, so it shouldn't cause delays or anything like that.
Having it running by default means that the data is available should it be required. It also means that bugs in it are found quicker (It made you are none voluntary bug-tester ;) ).
Switching it off could be useful for people using a laptop on battery power, who do not want any action on idle, and rather save battery. My guess is that serious debugging sessions on laptops are rather rare...

Well it does (meaning: bugs get fixed)
But you may miss out on features. e.g currently getting the list of threads does not work with the old version

BTW: next Lazarus release will support fpc 2.4.2?

don't know