Win64 (seh) compiled exe crashes, because implicit finally handler is entered twice.
Original Reporter info from Mantis: Martin @martin_frb
-
Reporter name: Martin Friebe
Original Reporter info from Mantis: Martin @martin_frb
- Reporter name: Martin Friebe
Description:
This happens on Win64 only (seh specific) / not tested with the 32 bit seh...
See code in "steps to reproduce"
compiled with -gh (tested with -gh -gt -gw) crashes.
The procedure allocates memory for a local copy of "a: array of integer"
When "exit" is executed, _FPC_local_unwind is called. This calls the finally handlers (both the user one, and the implicit one).
The following code is generated (-al)
>>>>>>>>>>>>>>>>>
.seh_handler __FPC_specific_handler,@unwind
.seh_handlerdata
.long 2
.long 0
.rva .Lj14
.rva .Lj15
.rva P$PROJECT1$_$FOO$array_of_LONGINT_$$_fin$0
.long 0
.rva .Lj9
.rva .Lj10
.rva P$PROJECT1$_$FOO$array_of_LONGINT_$$_fin$1
<<<<<<<<<<<<<<<<
Lj10 is BEFORE the call to the implicit finally
.Lj10:
.Lj11:
movq %rbp,%rcx
call P$PROJECT1$_$FOO$array_of_LONGINT_$$_fin$1
So after unwind finishes, the implicit finally handler is called a 2nd time (setting a breakpoint in asm proves this).
The memory for "a" is attempted to be freed a 2nd time, which crashes the app.
Steps to reproduce:
program project1;
{$mode objfpc}
uses
Classes;
procedure Foo(a: array of integer);
begin
try
writeln(a[0]);
if a[0] = 1 then exit;
writeln(a[0]);
finally
writeln(a[0]);
end;
end;
begin
foo([1]);
end.
Mantis conversion info:
- Mantis ID: 34772
- OS: win 10
- OS Build: 10
- Build: 40680
- Platform: 64bit Intel
- Version: 3.3.1
- Fixed in revision: 42673 (#416c974d)
- Monitored by: » xmen (xmen), » reiner.sombrowsky (Reiner Sombrowsky), » Snus (Snus), » @xhajt03 (Tomas Hajny), » Cyrax (Cyrax), » @MageSlayer (Denis Golovan), » @CuriousKit (J. Gareth Moreton)