Hi,

Since some versions gdb crashes with FPC programs if the "print" command is called with a query of pointer to not existing record fields for example, it triggers an assertion error. That makes gdb completely useless for use in IDE watch windows.
In gdb current git master (7.8.50.20141218-cvs) this problem is fixed but class fields are not known to gdb anymore, "print ftag" in a tcomponent descendant returns "Type TMAINFO has no component named ftag." with -g and -gw, with -gw3 it returns "No symbol "ftag" in current context." (FPC fixes_2_6, i386-linux).

Suggestions?

Thanks, Martin

Hi Martin,

it would be useful to have a
simple source code which allows to reproduce your problem, together with a list of the operations that lead to the assertion.

I am afraid that current trunk is not really usable with FP IDE, because there has be a lot of changes in C structs used that might disrupt gdbint.pp code.

But maybe I understood wrong and you are talking about the Lazarus IDE...

Pierre Muller

I talk about MSEide. ;-)
The assertion errors are already fixed in current gdb git master version, the problem with gdb git master is that it can not print FPC class fields.

If you like to reproduce the assertion in gdb release versions load the program:
https://gitorious.org/mseuniverse/mseuniverse/source/testcase/gdb/assertioncrash/invalidvar.pas

in gdb and enter the commands:
"
gdb ./invalidvar
GNU gdb (GDB; openSUSE 13.1) 7.6.50.20130731-cvs
[...]
(gdb) break main
Breakpoint 1 at 0x8049b78: file invalidvar.pas, line 17. (gdb) run
Starting program: /home/mse/proj/msegui/testcase/mse/gdb/invalidvar/invalidvar [...]
Breakpoint 1, main () at invalidvar.pas:17
17 po1:= @r1;
(gdb) print po1^.c
../../gdb/parse.c:592: internal-error: mark_struct_expression: Assertion `parse_completion && expout_tag_completion_type == TYPE_CODE_UNDEF' failed. A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
../../gdb/parse.c:592: internal-error: mark_struct_expression: Assertion `parse_completion && expout_tag_completion_type == TYPE_CODE_UNDEF' failed. A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n

"

Martin

Hi Martin,

I happen to have the whole series of official
GDB releases compiled for i386-linux
from 6.1a up to 7.8.1.
I found only 7.6, 7.6.1 and 7.6.2 that show your
problem.
With 7.7, 7.7.1, 7.8 and 7.8.1
I do get
Type RECTY has no component named C.

Did you try to use 7.7 or later release?

Pierre

I'll try to compile this versions, thanks.

Martin

See also http://bugs.freepascal.org/view.php?id=27136

Tony

Pierre Free Pascal wrote

Did you try to use 7.7 or later release?

gdb compiled from git gdb-7.8-branch 84aa7422f440868fea3359fde953c8375ca3409c works, thanks.
One probably should check why gdb git master (7.8.50) can not print FPC class field values.

Martin

No, it is not OK. FPC fixes_2_6 i386-linux -gl -O-:

With the MSEgui demo program
https://gitorious.org/mseide-msegui/mseide-msegui/source/apps/demo

gdb-7.8-branch (7.8.1):
"
[...]
Reading symbols from ./demo...done.
(gdb) break main.pas:25
Breakpoint 1 at 0x8099a5f: file main.pas, line 25. (gdb) run
Starting program: /home/mse/packs/standard/git/mseide-msegui/apps/demo/demo warning: Could not load shared library symbols for linux-gate.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Breakpoint 1, TMAINFO__EXITONEXECUTE (SENDER=0xb7a6a000, this=<error reading variable>) at main.pas:25
25 application.terminated:= true;
(gdb) print ftag
Type TMAINFO has no component named ftag.
(gdb) print self.ftag
warning: can't find linker symbol for virtual table for `TMAINFO' value $1 = 0
(gdb)
"

gdb-7.7-branch (7.7.1):
"
Reading symbols from ./demo...done.
(gdb) break main.pas:25
Breakpoint 1 at 0x8099a5f: file main.pas, line 25. (gdb) run
Starting program: /home/mse/packs/standard/git/mseide-msegui/apps/demo/demo warning: Could not load shared library symbols for linux-gate.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Breakpoint 1, TMAINFO__EXITONEXECUTE (SENDER=0xb7a6a000, this=<error reading variable>) at main.pas:25
25 application.terminated:= true;
(gdb) print ftag
Type TMAINFO has no component named ftag.
(gdb) print self.ftag
warning: can't find linker symbol for virtual table for `TMAINFO' value $1 = 0
(gdb)
"

gdb_7_6-branch (7.6.2):
"
Reading symbols
from /home/mse/packs/standard/git/mseide-msegui/apps/demo/demo...done. (gdb) break main.pas:25
Breakpoint 1 at 0x8099a5f: file main.pas, line 25. (gdb) run
Starting program: /home/mse/packs/standard/git/mseide-msegui/apps/demo/./demo warning: Could not load shared library symbols for linux-gate.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Python Exception <type 'exceptions.AttributeError'> 'gdb.Type' object has no attribute 'name':
Breakpoint 1, TMAINFO__EXITONEXECUTE (SENDER=0xb7a6a000, this=<error reading variable>) at main.pas:25
25 application.terminated:= true;
(gdb) print ftag
warning: can't find linker symbol for virtual table for `TMAINFO' value Python Exception <type 'exceptions.AttributeError'> 'gdb.Type' object has no attribute 'name':
Python Exception <type 'exceptions.AttributeError'> 'gdb.Type' object has no attribute 'name':
$1 = 0
(gdb) print self.ftag
warning: can't find linker symbol for virtual table for `TMAINFO' value Python Exception <type 'exceptions.AttributeError'> 'gdb.Type' object has no attribute 'name':
Python Exception <type 'exceptions.AttributeError'> 'gdb.Type' object has no attribute 'name':
$2 = 0
(gdb)
"

gdb_7_5-branch (7.5.1):
"
Reading symbols
from /home/mse/packs/standard/git/mseide-msegui/apps/demo/demo...done. (gdb) break main.pas:25
Breakpoint 1 at 0x8099a5f: file main.pas, line 25. (gdb) run
Starting program: /home/mse/packs/standard/git/mseide-msegui/apps/demo/demo warning: Could not load shared library symbols for linux-gate.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Breakpoint 1, TMAINFO__EXITONEXECUTE (SENDER=0xb7a6a000, this=<error reading variable>) at main.pas:25
25 application.terminated:= true;
(gdb) print ftag
$1 = 0
(gdb) print self.ftag
$2 = 0
(gdb)
"

With the "assertion crash" program
https://gitorious.org/mseuniverse/mseuniverse/source/testcase/gdb/assertioncrash/invalidvar.pas

gdb-7.8-branch (7.8.1):
"
Reading symbols from ./invalidvar...Reading symbols from /home/mse/packs/standard/git/mseuniverse/testcase/gdb/assertioncrash/invalidvar.dbg...done. done.
(gdb) print po1^.c
Type RECTY has no component named c.
(gdb)
"

gdb-7.7-branch (7.7.1):
"
Reading symbols from ./invalidvar...Reading symbols from /home/mse/packs/standard/git/mseuniverse/testcase/gdb/assertioncrash/invalidvar.dbg...done. done.
(gdb) print po1^.c
Type RECTY has no component named c.
(gdb)
"

gdb_7_6-branch (7.6.2):
"
Reading symbols
from /home/mse/packs/standard/git/mseuniverse/testcase/gdb/assertioncrash/invalidvar...Reading symbols
from /home/mse/packs/standard/git/mseuniverse/testcase/gdb/assertioncrash/invalidvar.dbg...done. done.
(gdb) print po1^.c
parse.c:588: internal-error: mark_struct_expression: Assertion `parse_completion && expout_tag_completion_type == TYPE_CODE_UNDEF' failed. A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
"

gdb_7_5-branch (7.5.1):
"
Reading symbols
from /home/mse/packs/standard/git/mseuniverse/testcase/gdb/assertioncrash/invalidvar...Reading symbols
from /home/mse/packs/standard/git/mseuniverse/testcase/gdb/assertioncrash/invalidvar.dbg...done. done.
(gdb) print po1^.c
Type RECTY has no component named c.
(gdb)
"

So the last working gdb with FPC is 7.5.1.

Martin

Bug report:
http://bugs.freepascal.org/view.php?id=27188
I know that real Pascal programmers don't use a debugger, they use writeln(). ;-)

Martin