View Issue Details

IDProjectCategoryView StatusLast Update
0037305FPCCompilerpublic2020-07-16 18:44
Reporterolly Assigned To 
Status newResolutionopen 
Product 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 Revision
Attached Files


related to 0036774 new 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)

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