exception catch clause does work on Linux arm/arm64 for .net 6.0 release #62702
Comments
dotnet-issue-labeler
bot
added
the
untriaged
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
danmoseley
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsDescriptionexception catch clause does work on Linux arm/arm64 as expected for .net 6.0 release Reproduction Steps
or
Expected behaviorThe exception is caught and discarded silently Actual behaviorThe exception is not caught and cause the problem terminated. Regression?seems there is no such issue at .net 6.0 rc releases... Known Workaroundsno ConfigurationNo response Other informationNo response
|
|
@JulieLeeMSFT not the comment above suggests this is a regression. |
|
One interesting observation is that if throw exception directly in Main() but in func3(), then it can be caught without any problem. |
|
This doesn't repro for me, though I may not be following what you did exactly -- I built on an arm64 machine and did not copy the published app. Just running is ok: Publishing then running is ok: Can you give more details about the environment where you build and the environment where you run? |
Thanks for your taking a look. I just found it only can be reproduced with my local build using my project at https://gitbub.com/oldzhu/4dotnet with buildroot system. Another observation is that the issue also gone if I built the .net core master branch with my buildroot project 4dotnet. I am performing live debugging for my local repro and so far found the EHInfo ( phdrJitEHInfo) is null for the function main (seems like the EHInfo is not filled when the main was jitted). I will continue to investigate to figure out why or provide a repro which is not rely on my buildroot project. |
|
Update on the debugging progress. The issue looks like caused by the incorrect instructions generated for the below lines of the code in corhlpr.cpp and corhlpr.h: frame #0: 0x0000007ff77599f0 libcoreclr.so`::DecoderInit(pThis=0x0000007fffffe3c8, header=0x0000007ff28f42d4) at corhlpr.cpp:59:45
56 if (header->Fat.GetSize() >= (sizeof(COR_ILMETHOD_FAT) / 4)) // Size if valid
57 {
58 decoder->Sect = header->Fat.GetSect();
-> 59 if ((decoder->Sect != NULL) && (decoder->Sect->Kind() == CorILMethod_Sect_EHTable))
^
60 {
61 decoder->EH = (COR_ILMETHOD_SECT_EH *)decoder->Sect;
...
const COR_ILMETHOD_SECT* GetSect() const {
if (!More()) return (0);
return(((COR_ILMETHOD_SECT*) (GetCode() + GetCodeSize()))->Align());
}
...
const COR_ILMETHOD_SECT* Align() const
{
return((COR_ILMETHOD_SECT*) ((((UINT_PTR) this) + 3) & ~3));
}
good working instructions: 0x7ff783b58c <+144>: 0xb9400429 ldr w9, [x1, #0x4]
0x7ff783b590 <+148>: 0x53047d08 lsr w8, w8, #4
0x7ff783b594 <+152>: 0x531e7508 lsl w8, w8, #2
0x7ff783b598 <+156>: 0x8b080028 add x8, x1, x8
0x7ff783b59c <+160>: 0x8b090108 add x8, x8, x9
0x7ff783b5a0 <+164>: 0x91000d08 add x8, x8, #0x3
0x7ff783b5a4 <+168>: 0xf27ef508 ands x8, x8, #0xfffffffffffffffc
0x7ff783b5a8 <+172>: 0xf9001808 str x8, [x0, #0x30]
incorrect nonworking instructions: 0x7ff77599d4 <+136>: 0xb940042a ldr w10, [x1, #0x4]
0x7ff77599d8 <+140>: 0x121e0d08 and w8, w8, #0x3c
0x7ff77599dc <+144>: 0x8b080028 add x8, x1, x8
0x7ff77599e0 <+148>: 0x721d013f tst w9, #0x8
0x7ff77599e4 <+152>: 0x8b0a0108 add x8, x8, x10
0x7ff77599e8 <+156>: 0x9a8803e8 csel x8, xzr, x8, eq
0x7ff77599ec <+160>: 0xf9001808 str x8, [x0, #0x30]
comparing the working and nonworking instructions generated, could see the instructions for Align() function was not generated in the nonworking scenario, so that it read the EHTable from an incorrect un-aligned address. Suspect it is a bug in LLVM compiler toolchain, continue to investigate to see if can find a simple repro. |
rebuilt the new ARM linux vm with the .net runtime 6.0.1 + the patch to corhlpr.h in #62170, the exception gone. Will build ARM64 linux vm with the same too to confirm the issue also gone... |
|
Rebuilt the new ARM64 linux vm with the .net runtime 6.0.1 + the patch to corhlpr.h in #62170 and confirmed the issue gone too. The arm instructions for COR_ILMETHOD_SECT::Align() after the patch (lldb) disas -A thumbv7 -b -n COR_ILMETHOD_SECT::Align
libcoreclr.so`::DecoderInit(void *, COR_ILMETHOD *):
0xb697da9a <+230>: 0x3103 adds r1, #0x3
0xb697da9c <+232>: 0xf0210103 bic r1, r1, #0x3
0xb697daa0 <+236>: 0xe7ce b 0xb697da40 ; <+140> at corhlpr.h
The arm64 instructions for COR_ILMETHOD_SECT::Align() after the patch (lldb) disas -b -n COR_ILMETHOD_SECT::Align
...
libcoreclr.so`::DecoderInit(void *, COR_ILMETHOD *):
0x7ff775a388 <+336>: 0x91000d08 add x8, x8, #0x3
0x7ff775a38c <+340>: 0x927ef508 and x8, x8, #0xfffffffffffffffc
...
This issue can be closed |
ghost
locked as resolved and limited conversation to collaborators
Description
exception catch clause does work on Linux arm/arm64 as expected for .net 6.0 release
Reproduction Steps
or
Expected behavior
The exception is caught and discarded silently
Actual behavior
The exception is not caught and cause the program terminated.
Regression?
seems there is no such issue at .net 6.0 rc releases...
Known Workarounds
no
Configuration
No response
Other information
No response
The text was updated successfully, but these errors were encountered: