View Issue Details

IDProjectCategoryView StatusLast Update
0023365FPCCompilerpublic2012-11-24 14:18
ReporterBoris Popov Assigned ToJonas Maebe  
Status resolvedResolutionfixed 
Product Version2.7.1 
Target Version2.7.1 
Summary0023365: Compiler produces debug symbols which can not be read by gdb
Description  Recent versions of fpc 2.7.1 (no extact date at hands) started to produce possibly invalid debugging symbols which causes gdb 7.4 or 7.5 to either crash, or hang somewhere in the glibc malloc() code. This happens only with particular set of units. In particular, pay special attention to


clause in the weirdunit.pas unit. If one will comment out this statement, then fpc produces correct output and gdb no longer crashes on startup. In the attached archive there is also the backtrace of gdb crash.
Steps To ReproduceI've tried to reduce code to absolute minimum. The attached project can be compiled with recent version of Lazarus which should have bgrabitmap pack installed. To fix offending revision of bgrabitmappack.lpk it is also included in the archive.
Additional InformationGNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from test...Reading symbols from test.dbg...*** glibc detected *** gdb: malloc(): memory corruption: 0x00000000021c6970 ***
TagsNo tags attached.
Fixed in Revision23056
Attached Files


2012-11-21 16:31


dwarfbug.tgz (371,930 bytes)

Martin Friebe

2012-11-21 18:39

manager   ~0063955

Possible related to:
0023330 win32: line info using dwarf with trunk no longer regognized by gdb

Boris Popov

2012-11-22 13:19

reporter   ~0063966

Last edited: 2012-11-22 13:20

It seems, that the bug are strictly tied to x64 platform, because I'm unable to reproduce it on Ubuntu/Win/32.

Also, even with 'uses BGRABitmap' line commented out it is still possible to break gdb, which is usually (but not always) complains about undefined DWARF register.

It is also worth to note, that bgrabitmappack package seems to be ideal testcase because only projects which use this package trigger this bug.

And final note: recent tests shows that 2.6.1 with fixes are also affected.

Pierre Muller

2012-11-22 14:50

developer   ~0063970

Could you check that commit 23046 fixes this bug?

Thanks in advance

Pierre Muller

Boris Popov

2012-11-22 15:55

reporter   ~0063975

Nothing changed, symptoms are the same.

Boris Popov

2012-11-23 03:42

reporter   ~0063981

I've traced code in gdb and discovered the following: there are three related types of .stab entries: N_SOL, N_BINCL and N_EINCL. According to the sources, gdb expects N_EINCL after one or more of N_SOL or N_BINCL, but instead, it immediately hits the N_EINCL entry in an attempt to lookup symbol. This is treated as "internal error".

Boris Popov

2012-11-23 05:52

reporter   ~0063982

Last edited: 2012-11-23 05:55

2.6.1 produces slightly different pattern, but the final point is the same. The "PUSH:/POP:" pairs related to invocations of {push|pop}_subfile() functions in gdb with the string corresponding to entry name. N_* reflects the entry type which is currently processed:

(gdb) b main
PUSH: :7TOBJECT;2A*6;11;;DEFAULTHANDLERSTR::47=#0000003;:7TOBJECT3var;2A*7;11;;DISPATCH::48=#0000003;:7TOBJECT3var;2A*8;11;;DISPATCHSTR::49=#0000003;:7TOBJECT3var;2A*9;11;;GETINTERFACE::50=#0000008;:7TOBJECT5TGUID3out;2A.;GETINTERFACEBYSTR::51=#0000008;:7TOBJECT11SHORTSTRING3out;2A.;GETINTERFACEWEAK::52=#0000008;:7TOBJECT5TGUID3out;2A.;GETINTERFACEENTRY::53=##54;:11unnamedtype5TGUID;2A.;GETINTERFACEENTRYBYSTR::55=##54;:11unnamedtype11SHORTSTRING;2A.;GETINTERFACETABLE::56=#0000057;:11unnamedtype;2A.;UNITNAME::58=#0000059;:11unnamedtype10ANSISTRING;2A.;EQUALS::60=#0000008;:7TOBJECT7TOBJECT;2A*10;11;;GETHASHCODE::61=#0000013;:7TOBJECT;2A*11;11;;TOSTRING::62=#0000059;:7TOBJECT10ANSISTRING;2A*12;11;;;~%11;
PUSH: rus/components/lazpaint/bgrabitmap/
PUSH: rus/components/lazpaint/bgrabitmap/
POP: rus/components/lazpaint/bgrabitmap/
PUSH: rus/components/lazpaint/bgrabitmap/
POP: rus/components/lazpaint/bgrabitmap/
PUSH: rus/components/lazpaint/bgrabitmap/
POP: rus/components/lazpaint/bgrabitmap/
PUSH: rus/components/lazpaint/bgrabitmap/
POP: rus/components/lazpaint/bgrabitmap/
POP: rus/components/lazpaint/bgrabitmap/
POP: :7TOBJECT;2A*6;11;;DEFAULTHANDLERSTR::47=#0000003;:7TOBJECT3var;2A*7;11;;DISPATCH::48=#0000003;:7TOBJECT3var;2A*8;11;;DISPATCHSTR::49=#0000003;:7TOBJECT3var;2A*9;11;;GETINTERFACE::50=#0000008;:7TOBJECT5TGUID3out;2A.;GETINTERFACEBYSTR::51=#0000008;:7TOBJECT11SHORTSTRING3out;2A.;GETINTERFACEWEAK::52=#0000008;:7TOBJECT5TGUID3out;2A.;GETINTERFACEENTRY::53=##54;:11unnamedtype5TGUID;2A.;GETINTERFACEENTRYBYSTR::55=##54;:11unnamedtype11SHORTSTRING;2A.;GETINTERFACETABLE::56=#0000057;:11unnamedtype;2A.;UNITNAME::58=#0000059;:11unnamedtype10ANSISTRING;2A.;EQUALS::60=#0000008;:7TOBJECT7TOBJECT;2A*10;11;;GETHASHCODE::61=#0000013;:7TOBJECT;2A*11;11;;TOSTRING::62=#0000059;:7TOBJECT10ANSISTRING;2A*12;11;;;~%11;
buildsym.c:712: internal-error: failed internal consistency check

Although all these dwarfs are Greek to me, one can note that the last N_EINCL is unpaired and content of first and last push/pop looks a bit weird.

Jonas Maebe

2012-11-23 16:08

manager   ~0063987

":7TOBJECT;2A*6;11;;DEFAULTHANDLERSTR::47= ..." is Stabs debug info, not DWARF. N_BINCL/N_EINCL are also Stabs commands.

So somehow it seems you are using Stabs, not DWARF. Are you using a 32 or 64 bit compiler on your 64 bit Linux system? And what are the exact command line parameters you use? (you can ask Lazarus to show them: Project -> Project Options... -> Show Options, at the bottom) Maybe some different parameters are set for the BGRA package? (I have no idea about how to check that)

Stabs in general is not supported on 64 bit platforms, although the unbalanced BINCL/EINCL issue is unlikely to be 64 bit specific.

Boris Popov

2012-11-23 16:57

reporter   ~0063988

Yes! The offending option was in the bgrabitmap package - it explicitly sets type of symbols to stabs (-gs) ( I've changed it to system default (-g), relinked and everything works fine now! (this is a 64 bit compiler on 64 bit system).

Well, it is possible to detect this situation and issue a warning, or even better a fatal error to prevent these wonderful mistakes?

In any way, thanks for helping with the issue.

Jonas Maebe

2012-11-23 17:04

manager   ~0063989

Maybe we can now forbid Stabs on 64 bit platforms. It was initially allowed because it works somewhat, and we didn't have DWARF support yet at that point.

Jonas Maebe

2012-11-24 14:18

manager   ~0064000

I've disabled Stabs on 64 bit targets.

Issue History

Date Modified Username Field Change
2012-11-21 16:31 Boris Popov New Issue
2012-11-21 16:31 Boris Popov File Added: dwarfbug.tgz
2012-11-21 18:39 Martin Friebe Note Added: 0063955
2012-11-22 13:19 Boris Popov Note Added: 0063966
2012-11-22 13:20 Boris Popov Note Edited: 0063966
2012-11-22 14:50 Pierre Muller Note Added: 0063970
2012-11-22 14:58 Jonas Maebe Status new => feedback
2012-11-22 15:55 Boris Popov Note Added: 0063975
2012-11-22 21:47 Jonas Maebe Status feedback => new
2012-11-23 03:42 Boris Popov Note Added: 0063981
2012-11-23 05:52 Boris Popov Note Added: 0063982
2012-11-23 05:55 Boris Popov Note Edited: 0063982
2012-11-23 16:08 Jonas Maebe Note Added: 0063987
2012-11-23 16:09 Jonas Maebe Status new => feedback
2012-11-23 16:57 Boris Popov Note Added: 0063988
2012-11-23 17:04 Jonas Maebe Note Added: 0063989
2012-11-23 17:04 Jonas Maebe Status feedback => new
2012-11-24 14:18 Jonas Maebe Fixed in Revision => 23056
2012-11-24 14:18 Jonas Maebe Status new => resolved
2012-11-24 14:18 Jonas Maebe Resolution open => fixed
2012-11-24 14:18 Jonas Maebe Assigned To => Jonas Maebe
2012-11-24 14:18 Jonas Maebe Note Added: 0064000
2012-11-24 14:18 Jonas Maebe Target Version => 2.7.1