ARM: JIT crash #1397
Comments
|
Not sure, but maybe #1388 gone. I may change clang version on new Raspberry or maybe something changed in the runtime repo. |
|
What is the |
jkotas
added
the
area-NativeAOT-coreclr
|
Also #1388 is not gone,since if I publish empty console app, I still receive segmentation fault. |
|
I cannot reproduce that issue in not-NativeAOT context. Regular |
|
I would capture JIT dumps of the method in NativeAOT and in non-Native (make sure to turn off tiered JIT and R2R, and use same CoreLib build flavor in both cases), and then compare the two JIT dumps to find out why things are different in NativeAOT. |
|
I think I close to finding root cause of the issue. Part of JIT dump in NativeAOT. It seems that this is happens when this line processed: |
|
Stack trace for the issue following Based on what I see I think this is related to runtimelab/src/coreclr/jit/morph.cpp Lines 4366 to 4400 in 66d88cd Specifically line 4369 is skipped and as such tree does not transformed. At least this is one possible scenario if issue is close to execution path. If by some reason issue in different phase I do not know where to look at right now. I'm temporary without Raspberry right now, so I cannot get my hands on JIT dump for regular runtime application. |
|
Since this is around Maybe all that's needed is to update |
|
If I update |
|
Okay. I trying to better understand what's going on Problematicvector = Unsafe.As<T, Vector256<byte>>(ref tmp).AsVector(); OkayishVector128<byte> vec128 = Unsafe.As<T, Vector128<byte>>(ref tmp);
if (Vector<byte>.Count == 16)
{
vector = vec128.AsVector();
}This translated to following IL ProblematicOkayishAnd this is imports as following statements in basic blocks. Problematic 3 statementsOkayish 2 statementsAfter inlining and substitutions it comes down to Problematic 3 statementsOkayish 2 statementsI notice that line in log So my suspect that in |
|
I think I managed to get CoreCLR JIT. I do Frankend build in following way. I build NativeAOT Debug NativeAOT (not inlined, crash)Release CoreCLR (inlined, no crash) |
|
I was trying to test with |
|
You should also build and copy over debug CoreCLR System.Private.CoreLib.dll. It will give you |
I trying to avoid that, since I have only 16Gb flash, and that's mean I should remove locally runtimelab artifacts, and it would be slow, so I avoid that as much as possible. Linux at home allow me to cross compile, but I usually limited in cognitive throughput there. I definitely will try that as last resort. FIY: |
Hopefully, both these steps are going to fit into your 16GB flash.
Nice! |
|
I copy Checked CoreCLRI see following differences between CoreCLR and NativeAOT which may be related Debug NativeAOT Debug NativeAOT |
|
I have all answers on my questions after looking at source code. If you have This maybe not even an issue per-se, since code generated correctly, but definitely this is correctness error in these specific circumstances. I was trying to replicate with following code But seems to be |
This difference is caused by CoreCLR using ExtendedDefaultPolicy inlining policy by default and NativeAOT using DefaultPolicy by default. You can try passing in
Public System.Runtime.CompilerServices.Unsafe should behave identically. |
Same problem.
Also what area or ILC may be related to missing line |
My guess is that the ILC does not use Do you see |
This line is executed. |
|
This is tracked as dotnet/runtime#58518 in Runtime repo. |
During samples compilation. ARM built from 4424f85
During publish of HelloWorld sample. No modifications except local feed change.
The text was updated successfully, but these errors were encountered: