View Issue Details

IDProjectCategoryView StatusLast Update
0037305FPCCompilerpublic2021-03-14 22:23
Reporterolly Assigned ToFlorian  
Status resolvedResolutionfixed 
Product Version3.3.1 
Fixed in Version3.3.1 
Summary0037305: For loop with try finally statement using -O3 or -O4 causes SIGSEGV
DescriptionThe following happens on 3.2.0 and trunk (3.3.1).

This causes a SIGSEGV:

  i: Int32;
  for i := 0 to 10 do
  finally // SIGSEGV when finally is entered?

This however works:

  i: Int32;
  for i := 0 to 10 do
  begin // added begin block
    finally // works fine

However this doesn't work and FPC actually raises an error: "Compilation raised exception internally."

  i, j: Int32;
  for i := 0 to 1 do // FPC raises error here
      j := i;


TagsNo tags attached.
Fixed in Revision48972
Attached Files


related to 0036774 resolvedJuha Manninen Lazarus Using "make" to build Lazarus results in an access violation 



2020-07-07 00:22

reporter   ~0123791

Last edited: 2020-07-08 16:41

View 2 revisions

Forgot to add this only happens on windows (64 & 32) I cannot reproduce on Linux.

EDIT: It's only a issue with -O3 and -O4.

Bart Broersma

2020-07-07 13:11

reporter   ~0123798

Last edited: 2020-07-07 13:18

View 4 revisions

Example 1:
Crashes at runtime when compiled with -O3, but not with -O2, both fpc 3.2.0 and trunk r45606

Example 3:
Crashes the compiler with fpc 3.2.0 and trunk r45606 with -O3


2020-07-07 14:18

reporter   ~0123801

Olly, you mean 32bit compiler only?
Then this could be related to new win32 SEH.
Also interesting, compiler error happens with project option -O3,
but not with {$optimization Level3} only in unit.

Do-wan Kim

2020-07-08 08:22

reporter   ~0123810

004015E0 55 push %ebp
004015E1 89c5 mov %eax,%ebp
004015E3 e8f8ffffff call 0x4015e0 <fin$00000001>
004015E8 5d pop %ebp
004015E9 c3 ret

Compiler generate infinite function call. It makes crash.


2020-07-08 15:03

reporter   ~0123820

The severity should probably be a lot higher than Minor, sorry about that. Would be pretty broken if Lazarus 2.1.0 releases with this bug.

Sven Barth

2020-07-08 15:22

manager   ~0123821

There is nothing on the Lazarus side than can be done for this. And FPC 3.2.0 has just been released, so the next release with a potential bugfix will be at the earliest in around half a year.

Bart Broersma

2020-07-08 15:54

reporter   ~0123824

IIRC a long time a go fpc had a quick new release of a x.y.z version because of a similar issue, which then was called
If the fpc core team feels this bug (which is a regression) is serious enough, maybe this can be repeated.


2020-07-08 15:57

reporter   ~0123826

In times of CI and much more automation in general a next release should be available much faster. Especially if there are some serious bugs.
Just have a look at (Github also supports it but I think it's solved more nicely in Gitlab) which can simply create new releases based on scripts/config + host all versions of FPC/documentation + publish documentation + ...
Everything together at ONE central point (bugtracker, git history, documenation, commits, patches (MR), test suite results, ...) with a single software. Step forward into the decade of 20*0.


2020-07-08 16:39

reporter   ~0123831

Ah my bad. For some reason I was thinking 3.2 was still RC1 at the time of writing that previous message, that is obviously incorrect.
I guess if I'm the first to experience this issue it can't be that serious (but more than minor!)

Just be aware that with -O3 and -O4 try..finally statements in a for loop will blow up.


2020-07-11 21:58

administrator   ~0123894

@NoName: The main issue is that we basically to not have access to the infrastructure to do CI on all supported platforms (3.2.0 is released for >50 platforms). Not to mention that I doubt that the typical CI runner written in some "hype of the hour" language runs on all supported platforms.


2020-07-11 22:01

administrator   ~0123895

Clicked to fast :)

Not to mention the fact that CI requires that developers are available. The best CI pipeline does not help if building is broken by some external library change and nobody has the time to fix it. Good example is libgdb in this case. However, before the next release is done, such an issue needs to be fixed. In a volounteer project, this can take time.


2020-07-11 23:49

reporter   ~0123897

AFAIK the CI config gets converted to a bash script therefore it should run on at least all systems with bash support (+ Windows as it's an important target) - its just executing some commands like you would do manually to compile + run the tests. If you setup your environment by hand you just need to run the commands to compile FPC. Additionally a server is required which receives the command that it should download something (=new commit happened) but that could be written in any language I guess. Thus no special hype language needed for CI.
Only issue could be to connect an old PC to the internet like AMIGA. But you could probably run everything via QEMU? At least most of the platforms which should be enough to indicate serious issues which will affect many people (rare platforms are mostly hobbyist projects).


2020-07-12 07:33

reporter   ~0123904

this doesn't work
  i, j: Int32;
  for i := 0 to 1 do // FPC raises error here
      j := i;

but if you add
writeln(j) after j:=i it works !!


2020-07-12 08:20

administrator   ~0123907

@Noname: then this is no better than our current snapshots: Not to mention the fact that Marcus runs a Jenkins server ( but due to limited resources it does not cover all targets. However, I didn't see the Jenkins server fix any bugs yet caused by external changes ;)


2020-07-12 09:30

reporter   ~0123909

Last edited: 2020-07-13 20:04

View 6 revisions

After some loop-change, I get internal error 200309201
(related to exceptions, also known from 0032913)

k := -1;
for i := 0 to k do
      j := i;

The compiler does not remove such loop ( regardless of body content) completely.
Compiler versions (eg. 32bit FPC3.2 without SEH) which can run this without compile error in level o3,
generate a single line for this whole loop ( and also if other body content): mov eax,$FFFFFFFF


2020-07-12 10:01

reporter   ~0123911

Last edited: 2020-07-16 18:44

View 4 revisions

@codz: I wrapped each example in a procedure, and none of the examples compiles.
Code changes in try block and finally block have not removed the error.
For example, if each block contains only a function call, it still does not compile,
although there is nothing to optimize away.

1) All examples of this report compile/run
if FPC 3.2 was built with -dDISABLE_WIN32_SEH.

2) {$optimization noLOOPUNROLL}
seems to suppress errors in olly examples (loops with constant bounds).
And {$optimization LOOPUNROLL} leads to const loop error under all levels (O..O4)

ravi dion

2021-01-29 18:35

reporter   ~0128654

Just wanted to led you know that all versions are working fine with 3.2.1-r47846 - can be closed as solved?


2021-01-29 22:19

administrator   ~0128661

Thanks for the reminder, I forgot to mark it as resolved.

Fabio Luis Girardi

2021-02-24 23:30

reporter   ~0129153

This fix will be available to FPC 3.2.2 (if this version has been planned)?

Bart Broersma

2021-02-25 20:54

reporter   ~0129166

@Fabio: if it is in 3.2.1 then it will be in 3.2.2 release.

Fabio Luis Girardi

2021-02-25 23:31

reporter   ~0129168

@Bart sorry, I just checked the bug report header that mentions 3.3.1. I don't see the comment that mentions 3.2.1. Sorry again.


2021-03-10 16:57

reporter   ~0129549

Last edited: 2021-03-10 23:09

View 3 revisions

Tested 3.3.1 (r48931) win64 today. The orginal examples now run succesfully. However it's easy to recreate the issue with -O3 or -O4.

Runtime crash:

  i, j, c: Int32;
  c := 1;
  for i := 0 to c do // SIGSEGV at runtime
    j := i;
    if (j <> 0) then
      j := 0;

Compile time crash:

  i, j: Int32;
  for i := 0 to 1 do // Error: Compilation raised exception internally
    j := i;
    if (j <> 0) then
      j := 0;

J. Gareth Moreton

2021-03-10 18:55

developer   ~0129554

Reopened due to the report from olly.

J. Gareth Moreton

2021-03-10 22:16

developer   ~0129563

Can you just reconfirm the revision number? The trunk revision from a day or two ago was 48908.


2021-03-10 22:48

reporter   ~0129564

Sorry, that was the lazarus rev.

FPC rev is 48931. Used fpcupdeluxe eariler today for a complete fresh install.

Do-wan Kim

2021-03-12 15:17

reporter   ~0129606

Easy way to fix.
37305_forloopunroll.patch (1,430 bytes)   
Index: compiler/nflw.pas
--- compiler/nflw.pas	(revision 48940)
+++ compiler/nflw.pas	(working copy)
@@ -1766,12 +1766,21 @@
     constructor tfornode.create(l,r,_t1,_t2 : tnode;back : boolean);
+      var
+        blk:tblocknode;
+        st:tstatementnode;
          inherited create(forn,l,r,_t1,_t2);
          if back then
+         // avoid tryfinally block
+         if t2.nodetype=tryfinallyn then
+           begin
+             blk:=internalstatements(st);
+             addstatement(st,t2);
+             t2:=blk;
+           end;
     function tfornode.simplify(forinline : boolean) : tnode;
Index: compiler/optloop.pas
--- compiler/optloop.pas	(revision 48940)
+++ compiler/optloop.pas	(working copy)
@@ -78,7 +78,7 @@
     function checkcontrollflowstatements(var n:tnode; arg: pointer): foreachnoderesult;
-        if n.nodetype in [breakn,continuen,goton,labeln,exitn,raisen] then
+        if n.nodetype in [breakn,continuen,goton,labeln,exitn,raisen,tryfinallyn] then
37305_forloopunroll.patch (1,430 bytes)   


2021-03-12 17:34

reporter   ~0129611

If that's the fix, will likely need to check try except block too.

Do-wan Kim

2021-03-13 03:43

reporter   ~0129618

Only tryfinally node generate invalid infinite calling in finally section. No problem on tryexcept node.

Issue History

Date Modified Username Field Change
2020-07-06 23:30 olly New Issue
2020-07-07 00:22 olly Note Added: 0123791
2020-07-07 13:11 Bart Broersma Note Added: 0123798
2020-07-07 13:14 Bart Broersma Note Edited: 0123798 View Revisions
2020-07-07 13:18 Bart Broersma Note Edited: 0123798 View Revisions
2020-07-07 13:18 Bart Broersma Note Edited: 0123798 View Revisions
2020-07-07 14:18 nanobit Note Added: 0123801
2020-07-08 08:22 Do-wan Kim Note Added: 0123810
2020-07-08 15:03 olly Note Added: 0123820
2020-07-08 15:22 Sven Barth Note Added: 0123821
2020-07-08 15:54 Bart Broersma Note Added: 0123824
2020-07-08 15:57 NoName Note Added: 0123826
2020-07-08 16:39 olly Note Added: 0123831
2020-07-08 16:41 olly Note Edited: 0123791 View Revisions
2020-07-11 10:46 Mattias Gaertner Summary For loop with try finally statement using -O2 or -O3 causes SIGSEGV => For loop with try finally statement using -O3 or -O4 causes SIGSEGV
2020-07-11 10:46 Mattias Gaertner FPCTarget => -
2020-07-11 21:58 Florian Note Added: 0123894
2020-07-11 22:01 Florian Note Added: 0123895
2020-07-11 23:49 NoName Note Added: 0123897
2020-07-12 07:33 codz Note Added: 0123904
2020-07-12 08:20 Florian Note Added: 0123907
2020-07-12 09:30 nanobit Note Added: 0123909
2020-07-12 09:41 nanobit Note Edited: 0123909 View Revisions
2020-07-12 10:01 nanobit Note Added: 0123911
2020-07-12 10:33 nanobit Note Edited: 0123909 View Revisions
2020-07-12 10:40 nanobit Note Edited: 0123909 View Revisions
2020-07-13 15:18 Maxim Ganetsky Relationship added related to 0036774
2020-07-13 19:58 nanobit Note Edited: 0123909 View Revisions
2020-07-13 20:04 nanobit Note Edited: 0123909 View Revisions
2020-07-14 09:25 nanobit Note Edited: 0123911 View Revisions
2020-07-16 16:52 nanobit Note Edited: 0123911 View Revisions
2020-07-16 18:44 nanobit Note Edited: 0123911 View Revisions
2021-01-29 18:35 ravi dion Note Added: 0128654
2021-01-29 22:19 Florian Assigned To => Florian
2021-01-29 22:19 Florian Status new => resolved
2021-01-29 22:19 Florian Resolution open => fixed
2021-01-29 22:19 Florian Fixed in Version => 3.3.1
2021-01-29 22:19 Florian Note Added: 0128661
2021-02-24 23:30 Fabio Luis Girardi Note Added: 0129153
2021-02-25 20:54 Bart Broersma Note Added: 0129166
2021-02-25 23:31 Fabio Luis Girardi Note Added: 0129168
2021-03-10 16:57 olly Note Added: 0129549
2021-03-10 16:59 olly Note Edited: 0129549 View Revisions
2021-03-10 18:55 J. Gareth Moreton Status resolved => feedback
2021-03-10 18:55 J. Gareth Moreton Resolution fixed => open
2021-03-10 18:55 J. Gareth Moreton Note Added: 0129554
2021-03-10 22:16 J. Gareth Moreton Note Added: 0129563
2021-03-10 22:48 olly Note Added: 0129564
2021-03-10 22:48 olly Status feedback => assigned
2021-03-10 23:09 olly Note Edited: 0129549 View Revisions
2021-03-12 15:17 Do-wan Kim Note Added: 0129606
2021-03-12 15:17 Do-wan Kim File Added: 37305_forloopunroll.patch
2021-03-12 17:34 olly Note Added: 0129611
2021-03-13 03:43 Do-wan Kim Note Added: 0129618
2021-03-14 22:23 Florian Status assigned => resolved
2021-03-14 22:23 Florian Resolution open => fixed
2021-03-14 22:23 Florian Fixed in Revision => 48972