View Issue Details

IDProjectCategoryView StatusLast Update
0032352FPCCompilerpublic2020-09-24 12:03
ReporterCyrax Assigned ToFlorian  
Status resolvedResolutionfixed 
PlatformLinux x86_64OSArch 
Product Version3.1.1 
Summary0032352: Compiling DoubleCommander project sometimes gives "Fatal: Internal error 200611031" message.
DescriptionThis happens randomly during a compliation of DoubleCommander project.

Attached archive contains the compiler output.
TagsNo tags attached.
Fixed in Revision44026
Attached Files


has duplicate 0034823 closedBart Broersma revision 59992 breaks crossbuilding win32 lcl on macOS. 
has duplicate 0034843 closedBart Broersma Cannot build macOS IDE, FPC internal error 
has duplicate 0036152 closedFlorian svn version 61993 breaks building carbon-based lazarus. 
related to 0037478 new Compilation exception after dependency recompilation 



2017-08-28 16:49


compiler_output.gz (1,515 bytes)


2017-08-28 16:54

reporter   ~0102469

Recompiling project won't work, only full rebuild works.

Marco van de Voort

2017-12-30 19:26

manager   ~0105156

I tried to find the sourceline ugraphics.pas:269, but it seems that file in SVN only has about 100 lines?

We'll need some reproducable case.

Bart Broersma

2018-02-06 18:58

reporter   ~0106264

Last edited: 2018-02-11 18:02

View 2 revisions

From ML:
While building Lazarus/LCL

win32wsmenus.pp(253,1) Error: Internal error 200611031
I didn't touch the mentioned file.
FPC version is
Free Pascal Compiler version 3.0.4 [2017/10/06]
OS Windows 10, Lazarus SVN trunk 57257


2018-03-29 02:00


compiler output 2.tar.gz (12,159 bytes)


2018-03-29 02:01

reporter   ~0107461

Attached updated compiler output which does have more info.

Dirk Fellenberg

2018-05-31 16:06

reporter   ~0108621

### My observations on this:

This bug has been around for years, so it's not fpc3 specific.
In a more complex project, the error occurs when the signature of a unit interface has changed and you run a make.
The error position is displayed completely wrong in an unchanged unit oder a line after end of file.
The solution is a build instead of a make.

Unfortunately, I can't create a small demo, which reproduces the error.

The `internalerror(200611031)` is generated in `compiler/symsym.pas` by procedure `tprocsym.deref`. The code there exists in this form since 2006.

Benito van der Zander

2018-10-02 13:16

reporter   ~0111191

I pretty much get this every other day now

Thaddy de Koning

2018-10-02 13:34

reporter   ~0111194

I have never seen it apart from bug reports and there it could be reproduced by me too.
Maybe because my style of programming: initialize everything. (Which is not necessarily always a good thing)

Sven Barth

2018-10-02 15:54

manager   ~0111201

@Benito van der Zander: if you can reduce the problem to a small number of units that would be highly appreciated.

Benito van der Zander

2018-10-06 23:54

reporter   ~0111292

Perhaps the fpcdebug file helps?

Benito van der Zander

2018-10-13 14:25

reporter   ~0111391

Last edited: 2018-10-13 14:29

View 2 revisions

I did not realize a new compilation only appends to fpcdebug rather than rewriting the file, so you can ignore the first million lines of my file, they are all from previous issues...

Perhaps this is the relevant part:

00008000:Searching file /home/theo/hg/components/pascal/data/xquery.pas... found
00004000:(10011) PPU Source: /home/theo/hg/components/pascal/data/xquery.pas time 2018/10/06 18:38:37
00004000:(10027) Load from XQUERY (interface) unit SIMPLEHTMLTREEPARSER
00008000:Searching file lib/x86_64-linux/simplehtmltreeparser.ppu... found


00004000:(10027) Load from SIMPLEHTMLTREEPARSER (implementation) unit XQUERY


00004000:(10028) Recompiling simplehtmltreeparser, checksum changed for lib/x86_64-linux/xquery.ppu {impl}
00004000:(10051) Flag for reload: XQUERY
00004000:(10052) Forced reloading
00004000:(10058) Re-resolving unit XQUERY
10000001:/home/theo/hg/components/pascal/data/xquery.pas(550,1) Fatal: Internal error 200611031

The checksum has changed, but the source has not

Benito van der Zander

2019-01-05 15:44

reporter   ~0113191

It is still happening with r40721

And it is not random. Once it happens, it always happens, till something else has happened.

Here it happens:

fpc -MObjFPC -Scaghi -Cg -O1 -g -gl -l -vewnhibq -Fidata -Fi../lazarus/dialogs -Fiimport/synapse -Fudata -Fuinternet -Fuimport/regexpr/source -Fu../lazarus/dialogs -Fuimport/synapse -Fusystem -Fu../../../components/pascal/import/flre/src -Fuimport/flre/src -Fu../../../opt/lazarus/packager/units/x86_64-linux -Fu. -FUlib/x86_64-linux internettools.pas

Here it does not happen:

fpc -MObjFPC -Scaghi -Cg -O1 -g -gl -l -vewnhibq -Fi../../../components/pascal/import/synapse -Fu../../../components/pascal/import/synapse -Fu../../../components/lazarus/dialogs -Fu../../../components/lazarus/internet/sendBackError -Fu../../../components/pascal/data -Fu../../../components/pascal/system -Fu../../../components/pascal/internet -Fuandroid -Fu../../../components/lazarus/internet -Fu../../../components/pascal/data/lib/x86_64-linux -Fu../../../../../benito/hg/components/pascal/data/lib/x86_64-linux -Fu../../../../opt/lazarus/lcl/units/x86_64-linux/gtk2 -Fu../../../../opt/lazarus/lcl/units/x86_64-linux -Fu../../../../opt/lazarus/components/lazutils/lib/x86_64-linux -Fu../../../components/pascal/lib/x86_64-linux -Fu../../../../opt/lazarus/packager/units/x86_64-linux -Fu. -dLCL -dLCLgtk2 -dCOMPILE_SYNAPSE_INTERNETACCESS internettools.pas

After changing the defines, it does not happen anymore with either command

Jonas Maebe

2019-01-06 21:37

manager   ~0113219

I have done a bunch of fixes in r40789 that could cause crc changes in the interface related to "inline".

Additionally, specifying "noreturn" in the implementation but not in the interface is no longer allowed (it also caused an interface crc change).

Karl-Michael Schindler

2019-01-06 22:01

reporter   ~0113220

Unfortunately, the build error when crossbuilding win32 lcl on macOS went away, after i deleted all ppu files and 2 times of "make clean". So, my test case is lost.

Jonas Maebe

2019-01-06 22:08

manager   ~0113221

You would have had to rebuild everthing with the new compiler to test anyway.

Bart Broersma

2019-01-06 23:56

reporter   ~0113227

Changing the file on which the compiler chokes usually makes the error go away.

Benito van der Zander

2019-01-07 23:38

reporter   ~0113244

Not sure if it matters, but I think most my trouble started when I defined these types:

  TXQMapDuplicateResolve = (xqmdrReject, xqmdrUseFirst, xqmdrUseLast, xqmdrCombine);
  TXQMapDuplicateResolveHelper = type helper for TXQMapDuplicateResolve
    procedure setFromString(const s: string);

  TXQJsonParser = object
      TOption = (jpoAllowMultipleTopLevelItems, jpoLiberal, jpoAllowTrailingComma, jpoEscapeCharacters, jpoJSONiq);
      TOptions = set of TOption;
    context: PXQEvaluationContext;
    options: TOptions;
    duplicateResolve: TXQMapDuplicateResolve;
    escapeFunction: TXQValueFunction;
    procedure init;
    procedure setConfigFromMap(const map: IXQValue);
    function parse(argc: SizeInt; args: PIXQValue): IXQValue;
    function parse(const data: string): IXQValue;
    class function parse(const data: string; someOptions: TOptions): IXQValue; static;


2019-05-17 00:35

reporter   ~0116228

As on FPC trunk r42086, this bug still occurs but only if some units in LCL package is changed. Rebuilding whole DoubleCommander project fixes this.

Benito van der Zander

2019-05-24 12:29

reporter   ~0116389

I can reproduce it!

3 steps:

1. First you compile main.pas

2. You remove TXQMap* types and procedure, and compile main.pas again.

3. Then you undo the removal and compile the original main.pas again (712 bytes)

Karl-Michael Schindler

2019-10-09 00:06

reporter   ~0118431

I get this error with the fixes branch of lazarus 2.0 after svn commit 61993. Even after a make clean, it is still there, reproducible:

Compiling imglist.pp
controls.pp(473,1) Fatal: Internal error 200611031
Fatal: Compilation aborted

with ppc386, but not with ppcx64. Before trying a dual make clean, is there anything else, i could do to investigate this further?


2019-10-19 20:00

administrator   ~0118712

@Benito: Thanks for the small example. I made a patch which fixes this, but to be honest, I have no clue if it breaks other things, so please everybody, test the attached patch and tell me how it works. The affected unit loading code is unfortunaly the most complex code I ever encountered and for almost 20 years it is subject to be rewritten but nobody felt capable yet to do so.
tw32352.patch (671 bytes)   
diff --git a/compiler/fppu.pas b/compiler/fppu.pas
index b25b27bbd0..8659368e7d 100644
--- a/compiler/fppu.pas
+++ b/compiler/fppu.pas
@@ -2046,7 +2046,9 @@ var
                { When we don't have any data stored yet there
                  is nothing to resolve }
-               if interface_compiled then
+               if interface_compiled and
+                 { it makes no sense to re-resolve the unit if it is already finally compiled }
+                 not(state=ms_compiled) then
tw32352.patch (671 bytes)   


2020-09-24 12:03

reporter   ~0125815

For the record.
I experienced almost exactly the same thing as Karl (2019-10-09 00:06) . It was on a VM I use to build release versions of my app. Its 64bit linux, I have built 386 and windows cross compilers. I normally build from a script that calls lazbuild but could demonstrate the problem from within the IDE.
It would build 64bit linux versions fine but would fail with "controls.pp(473,1) Fatal: Internal error 200611031" for each of the cross compilers.
I added a blank line at 473 and the problem "went away". Sigh ...

Issue History

Date Modified Username Field Change
2017-08-28 16:49 Cyrax New Issue
2017-08-28 16:49 Cyrax File Added: compiler_output.gz
2017-08-28 16:54 Cyrax Note Added: 0102469
2017-12-30 19:26 Marco van de Voort Note Added: 0105156
2018-02-06 18:58 Bart Broersma Note Added: 0106264
2018-02-11 18:02 Bart Broersma Note Edited: 0106264 View Revisions
2018-03-29 02:00 Cyrax File Added: compiler output 2.tar.gz
2018-03-29 02:01 Cyrax Note Added: 0107461
2018-05-31 16:06 Dirk Fellenberg Note Added: 0108621
2018-10-02 13:16 Benito van der Zander Note Added: 0111191
2018-10-02 13:34 Thaddy de Koning Note Added: 0111194
2018-10-02 15:54 Sven Barth Note Added: 0111201
2018-10-06 23:54 Benito van der Zander Note Added: 0111292
2018-10-13 14:25 Benito van der Zander Note Added: 0111391
2018-10-13 14:29 Benito van der Zander Note Edited: 0111391 View Revisions
2019-01-05 15:44 Benito van der Zander Note Added: 0113191
2019-01-06 17:14 Bart Broersma Relationship added has duplicate 0034823
2019-01-06 21:37 Jonas Maebe Note Added: 0113219
2019-01-06 21:37 Jonas Maebe Status new => feedback
2019-01-06 22:01 Karl-Michael Schindler Note Added: 0113220
2019-01-06 22:08 Jonas Maebe Note Added: 0113221
2019-01-06 23:56 Bart Broersma Note Added: 0113227
2019-01-07 23:38 Benito van der Zander Note Added: 0113244
2019-01-09 22:58 Bart Broersma Relationship added has duplicate 0034843
2019-05-17 00:35 Cyrax File Added: compiler_output3.tar.gz
2019-05-17 00:35 Cyrax Note Added: 0116228
2019-05-17 00:35 Cyrax Status feedback => new
2019-05-24 12:29 Benito van der Zander File Added:
2019-05-24 12:29 Benito van der Zander Note Added: 0116389
2019-10-09 00:06 Karl-Michael Schindler Note Added: 0118431
2019-10-13 11:14 Florian Relationship added has duplicate 0036152
2019-10-19 20:00 Florian File Added: tw32352.patch
2019-10-19 20:00 Florian Note Added: 0118712
2020-01-23 21:57 Florian Assigned To => Florian
2020-01-23 21:57 Florian Status new => resolved
2020-01-23 21:57 Florian Resolution open => fixed
2020-01-23 21:57 Florian Fixed in Revision => 44026
2020-01-23 21:57 Florian FPCTarget => -
2020-08-08 21:40 Jonas Maebe Relationship added related to 0037478
2020-09-24 12:03 David Note Added: 0125815