View Issue Details

IDProjectCategoryView StatusLast Update
0031683FPCCompilerpublic2019-08-10 10:44
ReporterEric HeijnenAssigned To 
Status newResolutionopen 
Platformx86_64OSWindowsOS Version7
Product Version3.0.2Product Build2017/02/17 
Target VersionFixed in Version 
Summary0031683: unhandled exception while compiling project
DescriptionEvery now and then (randomly) when I do a (quick)compile of my project, fpc will crash with an unhandled exception

An unhandled exception occurred at $0000000100052BED:
EAccessViolation: Access violation

Doing a full build will fix the problem (just takes a bit longer)

(I've attached a full compile log for what it's worth)
Steps To ReproduceGet the project from

1: edit something in mainunit.pas,
2: (quick)compile
3: goto 1

eventually fpc will fail compiling and give the error
TagsNo tags attached.
Fixed in Revision
Attached Files


Eric Heijnen

2017-04-20 01:03

reporter (372,874 bytes)

Eric Heijnen

2019-08-10 10:20

reporter   ~0117621

Last edited: 2019-08-10 10:44

View 5 revisions

Found a sure way to cause this on the fpc 3.2.0 fixes branch:
First compile the project
Then go to mainunit.pas and just add anything to the interface section of the file (also works on other files but not sure if that's a 100% one)
Then do a quick compile and an exception during compilation will happen

e.g before repeatscantimer:integer; place a whatever:integer;

it gives a stacktrace but no symbolnames. I tried to compile fpc with debug symbols, and I can step through rtl code fine now, but still no symbolnames in the stacktrace

Eric Heijnen

2019-08-10 10:43

reporter   ~0117622

Ok, I managed to attach gdb to fpc and using *info to get some data:
original stacktrace:

top 3:
0x10004111d is in FULLTYPENAME (symtable.pas:2889).
2884 s1:=tabstractrecorddef(def).RttiName
2885 else
2886 s1:=def.typename;
2887 { When the names are the same try to include the unit name }
2888 if assigned(otherdef) and
2889 (def.owner.symtabletype in [globalsymtable,staticsymtable]) then
2890 begin
2891 s2:=otherdef.typename;
2892 if upper(s1)=upper(s2) then
2893 s1:=def.owner.realname^+'.'+s1;


0x1000e0654 is in FIND_WRONG_PARA (htypechk.pas:3530).
3525 FullTypeName(wrongpara.vardef,pt.left.resultdef))
3526 end
3527 else
3528 CGMessagePos3(pt.left.fileinfo,type_e_wrong_parameter_type,tostr(hp^.wrongparanr),
3529 FullTypeName(pt.left.resultdef,wrongpara.vardef),
3530 FullTypeName(wrongpara.vardef,pt.left.resultdef));
3531 end;
3534 procedure check_ranges(const location: tfileposinfo; source: tnode; destdef: tdef);


0x1000fc067 is in PASS_TYPECHECK (ncal.pas:3716).
3711 because wrong size is already checked. procdefinition
3712 is filled with the first (random) definition that is
3713 found. We use this definition to display a nice error
3714 message that the wrong type is passed }
3715 candidates.find_wrong_para;
3716 candidates.list(true);
3717 {$ifdef EXTDEBUG}
3718 candidates.dump_info(V_Hint);
3719 {$endif EXTDEBUG}


If you need more let me know

Issue History

Date Modified Username Field Change
2017-04-20 01:03 Eric Heijnen New Issue
2017-04-20 01:03 Eric Heijnen File Added:
2019-08-10 10:20 Eric Heijnen Note Added: 0117621
2019-08-10 10:22 Eric Heijnen Note Edited: 0117621 View Revisions
2019-08-10 10:24 Eric Heijnen Note Edited: 0117621 View Revisions
2019-08-10 10:24 Eric Heijnen Note Edited: 0117621 View Revisions
2019-08-10 10:43 Eric Heijnen Note Added: 0117622
2019-08-10 10:44 Eric Heijnen Note Edited: 0117621 View Revisions