Debugger Warning after upgrade to 2.2.0

[bobonwhidbey]

I recently upgraded to Laz 2.2.0 so I'm suspicious that there's a connection. When I compile and start to run a program (F9) that has been working for many years I get the attached error message. Any idea how to prevent this error?

[bobonwhidbey]

That was already checked as an option. The error messages have gone away after building the project and rebuilding the packages used by the project.

I've noticed that OpenFile dialogs seem to take a lot longer than before. Around 10 seconds when in debug mode. Still very fast when running from the EXE (not the IDE).

[Martin_fr]

According to your signature: 32 Bit Lazarus IDE, on a Win64 machine?

This is a weird one....  But before we go there....

1) You probably upgraded, so the IDE kept your config and you still use gdb. You really should change to FpDebug.
(unless you cross debug to 64bit, then you should use a 64bit IDE / or if you debug into dll written is pascal)


2) You can downgrade GDB.
There is an "alternative gdb" section on Sourceforge (in the "Windows 32" section).
I think 7.7.1 was used before.
https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032%20bits/Alternative%20GDB/

The current 9.2 gdb eliminated some other issues (eg some unicode issues), hence it was chosen. It did pass various tests.
But apparently not in your case....
gdb 10 was tested, and found to have more issues when used in the IDE. (newer versions have yet to be tested again...., but currently more priority goes towards fpdebug)


3) About the actual error.
It's an assertion in GDB. It can't be fixed by us.

There are various such issues, but I did not run into them during my testing.
And other GDB (older and newer) have other issues.
So there is no good gdb, also no best gdb. Depending on each persons needs (i.e. what code and data you have in your app), a different version of gdb is better.

I have seen assertions by gdb, where the assertion was definitely wrong, and the data (dwarf info from fpc) was correct. There may be cases were it is the other way round.
The assertion in this case makes no sense, but it may be the dialog did not capture enough context.

I don't expect that much can be done about it, but if you want you can sent a logfile
https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session


4)
This has absolutely nothing todo with "external debug info".


 

[Martin_fr]

That was already checked as an option. The error messages have gone away after building the project and rebuilding the packages used by the project.

Then maybe some file had old/outdate data, and when combined with the other units, it actually caused invalid debug info.
In that case GDB would have been right.
And in that case, you do not need to downgrade gdb.

You should still consider FpDebug, unless there are specific reasons (such as dll debugging.)

---------------
About the "open dialog" => That always has been an issue with gdb.

There is an option in the debugger settings "DisableLoadSymbolsForLibraries".

And also FpDebug fares better on this issue

[bobonwhidbey]

Yes - I'm using GDB debugger.  How can I change to FpDebug?

[Martin_fr]

Go to menu: Tools > Options
Then: Debugger > Backend

Check if the entry is already in the drop down. (part of the toolbar on top).

If not, "add" a new entry, and select "FpDebug ..." as type

[bobonwhidbey]

I added and selected the only FpDebug option "FpDebug internal Dwarf-debugger"

When I tried to compile, I got the attached choice. What's the choice I should choose?

[ccrause]

I added and selected the only FpDebug option "FpDebug internal Dwarf-debugger"

When I tried to compile, I got the attached choice. What's the choice I should choose?

All the options are in principle valid choices.  My preference is to select Enable Dwarf 3.

[Martin_fr]

For most people  "Dwarf 3" will get the best results (when using FpDebug).

If you go back to "gdb" this setting is kept (this is for each project / each project has its own setting).
"gdb" can use "dwarf 3", but gdb may crash with this setting. So for "gdb" it is recommended to use "dwarf with sets".

If you switch a lot between GDB and FpDebug, you may chose to use "dwarf with sets". FpDebug works well with that too (but all Locals / stack / etc will be upper-cased).

Also currently, if you debug code with "variant" variables, you need "dwarf with sets", even with FpDebug.