View Issue Details

IDProjectCategoryView StatusLast Update
0037305FPCCompilerpublic2020-07-16 18:44
Reporterolly Assigned To 
PrioritynormalSeverityminorReproducibilityalways
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:

var
  i: Int32;
begin
  for i := 0 to 10 do
  try
    writeln(i);
  finally // SIGSEGV when finally is entered?
  end;
end.

This however works:

var
  i: Int32;
begin
  for i := 0 to 10 do
  begin // added begin block
    try
      writeln(i);
    finally // works fine
    end;
  end;
end.

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

var
  i, j: Int32;
begin
  for i := 0 to 1 do // FPC raises error here
  begin
    try
      j := i;
    finally
    end;
  end;
end.

Thanks.


TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget-
Attached Files

Relationships

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

Activities

olly

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

nanobit

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.

olly

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 x.y.za.
If the fpc core team feels this bug (which is a regression) is serious enough, maybe this can be repeated.

NoName

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 https://gitlab.com/ (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.

olly

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.

Florian

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.

Florian

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.

NoName

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).

codz

2020-07-12 07:33

reporter   ~0123904

this doesn't work
var
  i, j: Int32;
begin
  for i := 0 to 1 do // FPC raises error here
  begin
    try
      j := i;
    finally
    end;
  end;
end.

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

Florian

2020-07-12 08:20

administrator   ~0123907

@Noname: then this is no better than our current snapshots: ftp://ftp.freepascal.org/pub/fpc/snapshot/v33/ Not to mention the fact that Marcus runs a Jenkins server (http://build.alb42.de:8080/) 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 ;)

nanobit

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
    try
      j := i;
    finally
    end;

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

nanobit

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