View Issue Details

IDProjectCategoryView StatusLast Update
0037902LazarusDebuggerpublic2020-10-12 00:22
Reporternanobit Assigned ToMartin Friebe  
Status closedResolutionfixed 
Product Version2.1 (SVN) 
Fixed in Version2.2 
Summary0037902: Project Debugger Backend is not always saved
DescriptionThe options in Project Options / Debugger / Debugger Backend
come from custom entries in IDE Options / Debugger / Debugger Backend.
Sometimes this can cause confusion, difficult to predict.

Mostly, the selection of "[GNU debugger (with fpdebug)]" (without custom name (prefix)) is not kept in project options:
After dialog close and reopen, the dialog shows "GNU debugger (gdb)" selected.

Workaround (seems to help):
In IDE Options, always define a (custom) name for each own Debugger Backend.
TagsNo tags attached.
Fixed in Revision63992
Attached Files


Martin Friebe

2020-10-09 20:18

manager   ~0126191

The entries in the project are not stored by name. Each entry has an oid/uuid.

Note that:
- Entries in project therefore will/should be kept, even if renamed in the global options
- Entries will follow updates to the global options (if the entry fpdebug, is changed to become gdb_fpdebug / by changing the entries class)

- Projects settings will not be valid, if the project is opened in a 2nd IDE (as the other IDE has different OIDs, ever if it has an identically configured entry)

Martin Friebe

2020-10-09 23:32

manager   ~0126197

I need better steps to reproduce.

I cleaned out my entire debugger config (new ide conf dir).
- Started the IDE
- Tools option > debugger > backend
- Pressed "add" / Changed to "gdb with fpdebug" / removed the proposed name "new" to empty (so to not have "new" as custom prefix)

As a result I have 2 backends configured.
[Gnu Debugger (gdb)]
[Gnu Debugger (with fpdebug)]

Went to project options > debugger
- changed from "ide default" to "[Gnu Debugger (with fpdebug)]"

closed and reopen project options => setting remained
reloaded project => setting remained
restarted IDE => setting remained

If you have a reproducible case, then please upload your environmentopitons.xml and the project lpi/lps files.
And steps to reproduce.

Please note:
If with the above setup you go to global options, and you change the dropdown under "Debugger type and path" (i.e. from "gdb+fpdebug" to "gdb" => then that change the name "[Gnu Debugger (gdb)] (2)" => and the project setting will follow this change.

It is still the same "custom setting", you only changed the dbg-class inside the custom setting.
The name is still empty / The name dropdown displays <empt name> + <class name> + "(2)"


2020-10-10 10:41

reporter   ~0126205

I cannot find the GUI steps to create a wrong environmentoptions.xml anymore.
But I know the old xml node <Debugger EventLogLineLimit="100"> ....</Debugger>
For posting here, I removed only xml attribute DebuggerFilename (does not change the outcome),
otherwise it's the original xml node: The IDE created UID duplicates (very strange).

If any environmentoptions.xml contains that debugger xml node,
one can select "[FpDebug internal Dwarf-debugger (beta)]" in Project settings (of any new project).
Then dialog close and reopen, where I see "[Gnu Debugger (gdb)]"
xmlDebuggerNode.txt (901 bytes)   
    <Debugger EventLogLineLimit="100">
      <WatchesDlg ColumnNameWidth="-1" ColumnValueWidth="-1"/>
      <CallStackDlg ViewCount="0"/>
        <Config ConfigClass="TFpGDBMIDebugger" UID="{2ABD1A25-EF6E-4871-846B-33BE0B08B389}"/>
        <Config ConfigClass="TGDBMIDebugger" UID="{2ABD1A25-EF6E-4871-846B-33BE0B08B389}"/>
        <Config ConfigClass="TFpDebugDebugger" UID="{2ABD1A25-EF6E-4871-846B-33BE0B08B389}"/>
        <Config ConfigName="(2)" ConfigClass="TFpDebugDebugger" UID="{2ABD1A25-EF6E-4871-846B-33BE0B08B389}"/>
        <Config ConfigName="(2) (2)" ConfigClass="TFpDebugDebugger" Active="True" UID="{2ABD1A25-EF6E-4871-846B-33BE0B08B389}"/>
xmlDebuggerNode.txt (901 bytes)   

Martin Friebe

2020-10-11 19:48

manager   ~0126242

This would explain the "not saved project settings" since the OID would point to both entries, and the wrong one could be chosen.

I found the problem / fixed in 63992

If an un-named entry (compatible with older IDE) was changed and the debugger-class was updated, then the entry was written to a new location in the XML. But the old entry was not removed. Therefore the XML now had 2 entries with the same OID. The 2nd entry would only become visible if the XML was loaded again.

Please test, and close if ok

The IDE will currently not fix such broken infos. You would have to remove them yourself (just change a digit in the OID). This code was not yet in any released version.


2020-10-12 00:22

reporter   ~0126249

This is also what I recall, the number of entries grew and I found no reason.
And it was a busy period where I installed FpDebug packages, rebuilt IDE and frequently changed gdb.exe paths.
This was quite a puzzle, thanks!

Issue History

Date Modified Username Field Change
2020-10-09 17:51 nanobit New Issue
2020-10-09 17:51 nanobit Status new => assigned
2020-10-09 17:51 nanobit Assigned To => Martin Friebe
2020-10-09 20:18 Martin Friebe Note Added: 0126191
2020-10-09 23:32 Martin Friebe Status assigned => feedback
2020-10-09 23:32 Martin Friebe LazTarget => -
2020-10-09 23:32 Martin Friebe Note Added: 0126197
2020-10-10 10:41 nanobit Note Added: 0126205
2020-10-10 10:41 nanobit File Added: xmlDebuggerNode.txt
2020-10-10 10:41 nanobit Status feedback => assigned
2020-10-11 19:48 Martin Friebe Status assigned => resolved
2020-10-11 19:48 Martin Friebe Resolution open => fixed
2020-10-11 19:48 Martin Friebe Fixed in Version => 2.2
2020-10-11 19:48 Martin Friebe Fixed in Revision => 63992
2020-10-11 19:48 Martin Friebe LazTarget - => 2.2
2020-10-11 19:48 Martin Friebe Widgetset Win32/Win64 => Win32/Win64
2020-10-11 19:48 Martin Friebe Note Added: 0126242
2020-10-12 00:22 nanobit Status resolved => closed
2020-10-12 00:22 nanobit Note Added: 0126249