try/catch/finally crashes clang

[levinli303]

Building this file

#import <Foundation/Foundation.h>

int main()
{
	@try {

	} @catch (NSException* e) {

	} @finally {

	};
	return 0;
}

with 09/12 toolchain

clang-cl -I C:\GNUstep\x64\Debug\include -fobjc-runtime="gnustep-2.0" -Xclang -fexceptions -Xclang -fobjc-exceptions -fblocks -DGNUSTEP -DGNUSTEP_WITH_DLL -DGNUSTEP_RUNTIME=1 -D_NONFRAGILE_ABI=1 -D_NATIVE_OBJC_EXCEPTIONS -DGSWARN -DGSDIAGNOSE /MDd /c test.m

clang crashes with

Stack dump:
0.      Program arguments: "C:\\Program Files\\LLVM\\bin\\clang-cl.exe" -I C:\\GNUstep\\x64\\Debug\\include -fobjc-runtime=gnustep-2.0 -Xclang -fexceptions -Xclang -fobjc-exceptions -fblocks -DGNUSTEP -DGNUSTEP_WITH_DLL -DGNUSTEP_RUNTIME=1 -D_NONFRAGILE_ABI=1 -D_NATIVE_OBJC_EXCEPTIONS -DGSWARN -DGSDIAGNOSE /MDd /c test.m
1.      <eof> parser at end of file
2.      test.m:3:5: LLVM IR generation of declaration 'main'
3.      test.m:3:5: Generating code for declaration 'main'
 #0 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x20c6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x20c52c9
 #1 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x20c4f8b C:\Program Files\LLVM\bin\clang-cl.exe 0x1f4c679
 #2 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x1f540d7 C:\Program Files\LLVM\bin\clang-cl.exe 0x1dc0cbf
 #3 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x1db9fd1 C:\Program Files\LLVM\bin\clang-cl.exe 0x1dbdd6b
 #4 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x1dc46ca C:\Program Files\LLVM\bin\clang-cl.exe 0x3e18c3f
 #5 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x3e16909 C:\Program Files\LLVM\bin\clang-cl.exe 0x2fa80f9
 #6 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x238a9c2 C:\Program Files\LLVM\bin\clang-cl.exe 0x23521bd
 #7 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x23f8c26 C:\Program Files\LLVM\bin\clang-cl.exe 0x75c3
 #8 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x47ff C:\Program Files\LLVM\bin\clang-cl.exe 0x22658c6
 #9 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x1b3d39f C:\Program Files\LLVM\bin\clang-cl.exe 0x22655b7
#10 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x21a9462 C:\Program Files\LLVM\bin\clang-cl.exe 0x21a9a09
#11 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x218bf26 C:\Program Files\LLVM\bin\clang-cl.exe 0x411d
#12 0x00007ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x3e367b8 (C:\Program Files\LLVM\bin\clang-cl.exe+0x20c6f9a)
#13 0x00007ff7d11e6f9a
#14 0x00007ff7d11e6f9a (C:\Program Files\LLVM\bin\clang-cl.exe+0x20c6f9a)
0x00007FF7D11E6F9A (0x00000270E6A49808 0x00000270E6C8E001 0x0000E037002A1F10 0x00000270E6A497E0)
0x00007FF7D11E52C9 (0x00000270E0AAEE50 0x00007FF7D291006D 0x000000C8F0B89BD0 0x000000C8F0B89BE0)
0x00007FF7D11E4F8B (0x0000000000000000 0x00007FF7D291D499 0x00000270E6A4BD68 0x00007FF7D062E1A0)
0x00007FF7D106C679 (0x0000000000000001 0x000000000000002B 0x00000270E6C732F0 0x0000E037002A1930)
0x00007FF7D10740D7 (0x0000000000000001 0x0000000000000000 0x000000C8F0B8A250 0x000000C8F0B8A1C0)
0x00007FF7D0EE0CBF (0x0000000000000000 0xFFFFFFFFFFFFFFFF 0x0000000000000000 0xFFFFFFFFFFFFFFFF)
0x00007FF7D0ED9FD1 (0x0000000000000003 0x00000270E23C7F30 0x00000270E6C736F0 0x00007FF7D2168455)
0x00007FF7D0EDDD6B (0x000000C8F0B8BCB8 0x0000000000000003 0x0000000000000000 0x00000270E0A84F20)
0x00007FF7D0EE46CA (0x00000270E23C7F40 0x000000C8F0B8D2A0 0x00000270E23CBE90 0x00007FF7D20CD082)
0x00007FF7D2F38C3F (0x00000270E23C7F30 0x0000000000000000 0x00000270E23C82D0 0x0000000000000000)
0x00007FF7D2F36909 (0x000000C8F0B8D3C8 0x000000C8F0B8D3B8 0x000000C8F0B8D3B8 0x00007FF7D147031A)
0x00007FF7D20C80F9 (0x0000000000000000 0x0000E037002A48A0 0x2D646E756F72522D 0x3163632D70697274)
0x00007FF7D14AA9C2 (0x00000000000000E8 0x00000270E0A883D0 0x0000000000000001 0x00000270E0A75D40)
0x00007FF7D14721BD (0x0000000000000000 0x0000000000000000 0x000000C8F0B8DDE8 0x00000270E0A00000)
0x00007FF7D1518C26 (0x000000C8F0B8D7C0 0x000000C8F0B8D658 0x000000C8F0B8D5A8 0x0000000000000000)
0x00007FF7CF1275C3 (0x0000000000000006 0x000000000000003F 0x000000C8F0005080 0x000000C837001126)
0x00007FF7CF1247FF (0x00007FF7D0C5D640 0x0000000000000000 0x00000270E0A74EA0 0x000000C8F0B8DF88)
0x00007FF7D13858C6 (0x00000270E0A74EA0 0x000000C8F0B8DF70 0x000000C8F0B8DF88 0x00007FF7D0C5D04B)
0x00007FF7D0C5D39F (0x000000C8F0B8DFD8 0x00000270E0A836E0 0x00000270E0A836E0 0x00007FF7D0C4278C)
0x00007FF7D13855B7 (0x0000000000000000 0x0000001000000000 0x0000000000000000 0x0000000000000060)
0x00007FF7D12C9462 (0x00000270E0A71970 0x00000270E0A71910 0x00000270E0A353E0 0x0000000000000026)
0x00007FF7D12C9A09 (0x0000000000000050 0x00007FFB33BC39CE 0x0000000000000000 0x0000000000000000)
0x00007FF7D12ABF26 (0x0000000000000051 0x0000027000000000 0x0000E04874267BC3 0x00000000000000BC)
0x00007FF7CF12411D (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0x00007FF7D2F567B8 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0x00007FFB33CD7034 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0x14 bytes(s)
0x00007FFB35CC2651 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x21 bytes(s)
clang-cl: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 13.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin

[triplef]

Thanks for the report. Is this with Clang 13.0.0 installed from the LLVM website?

@davidchisnall could you take a look at this?

[levinli303]

I installed via chocolatey.

C:\DEV>clang --version
clang version 13.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin

[davidchisnall]

Can you provide a reduced test case? To be able to debug this I need a preprocessed source file and the minimal compiler command to reproduce it.

[levinli303]

OK, these are the files generated by clang crash.zip

the minimal clang command would be clang-cl -I C:\GNUstep\x64\Debug\include -fobjc-runtime="gnustep-2.0" -Xclang -fobjc-exceptions /c test.m
crashes2.zip

[davidchisnall]

I am not actively using GNUstep or anything Objective-C related, and have almost no time to work on it at the moment. If there is a reduced test case, then I can take a look when I next have some spare time, but please try to provide something that doesn't include megabytes of headers.

[triplef]

@levinli303 can you try building this without GNUstep, maybe something like this:

clang-cl -fobjc-runtime="gnustep-2.0" -Xclang -fexceptions -Xclang -fobjc-exceptions /MDd /c test.m

You might have to replace "NSException" with "id" in the code.

[levinli303]

ok I removed import of Foundation and used id in place of NSException* crash.zip

[davidchisnall]

Minimal test case:

$ cat crash.m
int main()
{
        @try {
        } @catch (id e) {
        } @finally { };
}
$ clang -cc1 -triple x86_64-pc-windows-msvc -emit-obj -fobjc-runtime=gnustep-2.0 -fobjc-exceptions  -x objective-c crash.m

[davidchisnall]

It looks as if this is a bug in the Windows EH code for Objective-C with all runtimes. Clang is trying to pop something off the EH stack and expecting a catch but getting a cleanup. It crashes in the same place with any -fobjc-runtime= flag (e.g. macosx). Please can you file a clang bug for this? It's not in code that I'm familiar with and so I'm unlikely to have enough time to work on it this year but someone else might (especially with the reduced test case).

[levinli303]

thanks I will file a bug to llvm.

[triplef]

So I think this only happens when @finally is present, we just ran into this as well. @try/@catch without @finally works fine for us.

@levinli303 would be great if you could share the link to the LLVM bug here once you have filed it.

[levinli303]

@triplef you are right. if there is no @finally, clang does not crash.

the filed bug is here: https://bugs.llvm.org/show_bug.cgi?id=52557

[triplef]

Thanks! Could you maybe clarify in the bug that this specifically happens with @finally, and maybe add/reference this info from David (I don’t seem to have permissions to even add comments):

It looks as if this is a bug in the Windows EH code for Objective-C with all runtimes. Clang is trying to pop something off the EH stack and expecting a catch but getting a cleanup. It crashes in the same place with any -fobjc-runtime= flag (e.g. macosx).

@davidchisnall is there a way to bring this to the attention of anyone who might be familiar with the relevant code?

[levinli303]

@triplef I think LLVM is migrating the bug system from bugzilla to GitHub so I can't edit either. let's wait until the migration finishes. (Nov. 29 as it suggests.)

[triplef]

I remembered this comment from last year that I think is talking about the same issue:

I think the funclets for cleanups are incorrect in the SEH codegen (Windows only).

@DHowett-MSFT any chance you could take a look at this? https://bugs.llvm.org/show_bug.cgi?id=52557

[DHowett]

Interesting. This reminds me of LLVM-44483 "[Windows] evaluating a variable from an outer scope in a @finally inside a block causes an internal compiler error" as well. There's significant issues in @finally generation on Windows.

Unfortunately, I haven't had my compiler engineering hat on for a while now and can only invest at the "hobby" level ☹️

[levinli303]

FYI, the issue has been transferred to GitHub llvm/llvm-project#51899

[triplef]

@DHowett if you could take a look even at the "hobby" level that would certainly be appreciated! 🙏

(Another user ran into this issue with an existing large code base that is re-throwing exceptions from @finally, for which there’s no straight-forward workaround for this issue.)