View Issue Details

IDProjectCategoryView StatusLast Update
0035129LazarusDebuggerpublic2019-02-23 19:14
Reporternanobit Assigned ToMartin Friebe  
Status resolvedResolutionfixed 
Product Version2.0 
Fixed in Version2.0.2 
Summary0035129: Debug fails on interface variables
Descriptionlocal IUnknown variables confuse the debugger at function entry:
- if GNU debugger (with fpdebug): cannot step into function
- if GNU debugger (gdb): creates debugger message:

"While executing the command:
"TGDBMIDebuggerInstruction: "-stack-list-locals 1",
[ifRequiresThread, ifRequiresStackFrame, ifRequiresMemLimit, ifRequiresArrayLimit]
Thr=1 Frm=0" gdb reported: "&"gdbtypes.c:2151: internal-error:
type* resolve_dynamic_struct(type*, property_addr_info*):
Assertion `TYPE_NFIELDS (type) > 0' failed.\n
A problem internal to GDB has been detected,\n
further debugging may prove unreliable.\n""
Steps To Reproduceprogram project1;
{$mode objfpc}

  procedure fpDebug_stepIn_failure( unk: IUnknown);
  // debugFreeze if "GNU debugger (with fpdebug)"
   unk := nil;

  procedure testInterface;
  // starts with debugFailureMsg if "GNU debugger (gdb)"
  var unk: IUnknown;
   unk := nil;
   fpDebug_stepIn_failure( unk);

TagsNo tags attached.
Fixed in Revision60474
Attached Files


Martin Friebe

2019-02-21 13:01

manager   ~0114329

As for the gdb part, have you tried with an alternative gdb?

For gdb there is a known issue with stepping into/over interface methods (though may be different from this report) 0014399 0033009

Martin Friebe

2019-02-21 13:56

manager   ~0114330

I have trouble reproducing this.

I tried with a 32bit IDE, installed from official installer.
(Some subset tested on 64 bit IDE too)
Breakpoint on "testInterface" in the main program body, then step through all methods.

- pure gdb debugger, no problem
- gdb + fpdebug, no problem
- pure fpdebug, get an error, though different to yours. (and works in trunk)

Please attach a project with lpi. So I have the same project settings.


2019-02-21 18:30


project1.lpi (4,239 bytes)


2019-02-21 18:31

reporter   ~0114338

I use GDB version 8.2 for windows 32 bit and debugmode with dwarf3.

Martin Friebe

2019-02-21 20:12

manager   ~0114341

Both issues are caused by a crash in gdb. That cant be fixed by Lazarus.

In both cases, it is possible, but not known that an issue exists in the debug info written by fpc.
There are several cases where fpc generated dwarf3 (which may or may not be correct) and gdb do not get along.

In the 2nd case (gdb + fpdebug) there is an additional issue in the IDE, which is that the crash is not recognized. Therefore the IDE believes that the app is still running in the debugger.
This should be fixed, but will not help in debugging the app, as it is merely about telling the user that the debugger died.
Also the IDE is not hanging. In my case "stop" was still working. If stop fails: "reset debugger" will almost always do the trick.

On top of this, there are also issues in fpdebug itself. Running under pure fpdebug:
- "unk" is not in the "locals" window
- if "unk" is watched fpdebug also dies.

When looking into pure fpdebug, I will have to have a look at the generated dwarf3. If I find any issues with that, I will report those to the fpc team.

In any case there is a bug in gdb.

At this stage the only fixable part of this bug is, detecting the gdb crash.

And fixing pure fpdebug.

The only way currently to debug this app, is using dwarf2.

-------------------------------- for my own reference
gdb output case 1
>> TCmdLineDebugger.SendCmdLn "-stack-list-locals 1"
<< TCmdLineDebugger.ReadLn "&"gdbtypes.c:2151: internal-error: type* resolve_dynamic_struct(type*, property_addr_info*): Assertion `TYPE_NFIELDS (type) > 0' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\n""

gdb output case 2
DebuggerState: Finished dsRun
<< TCmdLineDebugger.ReadLn "&"gdbtypes.c:2151: internal-error: type* resolve_dynamic_struct(type*, property_addr_info*): Assertion `TYPE_NFIELDS (type) > 0' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\n""
[Debugger] Log output: &"gdbtypes.c:2151: internal-error: type* resolve_dynamic_struct(type*, property_addr_info*): Assertion `TYPE_NFIELDS (type) > 0' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\n"
<< TCmdLineDebugger.ReadLn "&"\nThis is a bug, please report it.""
[Debugger] Log output: &"\nThis is a bug, please report it."
<< TCmdLineDebugger.ReadLn "&" For instructions, see:\n<>.""
[Debugger] Log output: &" For instructions, see:\n<>."
<< TCmdLineDebugger.ReadLn "&"\n\n""
[Debugger] Log output: &"\n\n"
<< TCmdLineDebugger.ReadLn "&"Command aborted.\n""
[Debugger] Log output: &"Command aborted.\n"

Martin Friebe

2019-02-23 15:13

manager   ~0114365

The GDBMI+FpDebug debugger now show that gdb encountered an error.

More than one error will be shown, as subsequent internal commands fail too. (they only show, when the option is set to show all, and not "once per debug..."

In trunk an additional fix will show more complete feedback of the gdb error, and reduce the amount of individual errors.

If GDB does still live, then debugging can continue.
Though stepping inside that method may not work (maybe asm stepping). Using F9/Run should work.

The first error (without fpdebug), can maybe be suppressed by
- closing locals window
- closing or power off stack window
- power off "history" window (otherwise locals/stack will run anyway)
- making sure the interface variable is not watched

pure fpdebug is still in work, and will be fixed outside this issue

Martin Friebe

2019-02-23 16:43

manager   ~0114370

Having looked into it, I would guess the bug is indeed in gdb.

unk is DW_TAG_interface_type

The dwarf 3 says
The members of an interface are represented by debugging information entries that are owned by the interface type entry and that appear in the same order as the corresponding declarations in the source program

Unless I missed further info, from this it is not mandatory to have members (though an interface without members is pointless).

Fpc encodes the interface has having 0 (zero) size. And fpc does not encode any members.

By the look of gdb's error "Assertion `TYPE_NFIELDS (type) > 0'" I would guess that gdb refers to the absence of the members.

For all else this also means that (due to fpc) the interface can not be inspected. Well it does have an address that can be displayed. (Address of the 0 bytes of data, not of the "unk" variable).

Fpc also add a DW_AT_allocated info. Not sure about that. But dont think its causing the issue.


2019-02-23 19:05

reporter   ~0114373

Last edited: 2019-02-23 19:14

View 2 revisions

In the meantime (but before your changes) I found for the test project,
debugging (also dwarf3) works with gdb.exe v7.7.1, but not with v8.2.

In short, fpc is not compatible with v8.2. That means, either
gdb v8.2 has a bug, or
gdb v8.2 has no bug, but fpc needs to be upgraded to fullfil newer requirements of v8.2.

Issue History

Date Modified Username Field Change
2019-02-21 10:44 nanobit New Issue
2019-02-21 10:44 nanobit Status new => assigned
2019-02-21 10:44 nanobit Assigned To => Martin Friebe
2019-02-21 13:01 Martin Friebe Note Added: 0114329
2019-02-21 13:56 Martin Friebe LazTarget => -
2019-02-21 13:56 Martin Friebe Note Added: 0114330
2019-02-21 13:56 Martin Friebe Status assigned => feedback
2019-02-21 18:30 nanobit File Added: project1.lpi
2019-02-21 18:31 nanobit Note Added: 0114338
2019-02-21 18:31 nanobit Status feedback => assigned
2019-02-21 20:12 Martin Friebe Note Added: 0114341
2019-02-23 15:13 Martin Friebe Fixed in Revision => 60474
2019-02-23 15:13 Martin Friebe LazTarget - => 2.0.2
2019-02-23 15:13 Martin Friebe Note Added: 0114365
2019-02-23 15:13 Martin Friebe Status assigned => resolved
2019-02-23 15:13 Martin Friebe Fixed in Version => 2.0.2
2019-02-23 15:13 Martin Friebe Resolution open => fixed
2019-02-23 16:43 Martin Friebe Note Added: 0114370
2019-02-23 19:05 nanobit Note Added: 0114373
2019-02-23 19:14 nanobit Note Edited: 0114373 View Revisions