[ARM/Linux] Unit Test Regression - JIT/Regression/CLR-x86-JIT/V1.2-M01/b07369

[wateret]

Test Environment : arm-softfp / coreclr-release / TC-release

BEGIN EXECUTION
/opt/dotnet/Linux.arm-softfp.Release/corerun b07369.exe
./b07369.sh: line 117: 24912 Segmentation fault      $_DebuggerFullPath "$CORE_ROOT/corerun" b07369.exe $CLRTestExecutionArguments
Expected: 100
Actual: 139
END EXECUTION - FAILED

It's weird that segmentation fault happens only with coreclr-release and TC-release. Does not happen if at least one of these are debug.

[hqueue]

@wateret I also reproduced this regression with coreclr(361edab)(release built with -O1) and unix tests (x64, release) on arm-softfp.

[wateret]

Looks like there's something wrong during compilation, specifically range analysis.

(gdb) bt
#0  0xb21d3242 in ExpandArrayStack<ValueNumStore::Chunk*>::GetNoExpand(unsigned int) () from /opt/home/owner/0714r/libclrjit.so [expandarray.h:165]
dotnet/coreclr#1  0xb2242498 in ValueNumStore::GetVNFunc(unsigned int, VNFuncApp*) () from /opt/home/owner/0714r/libclrjit.so  [valuenum.cpp:3240]
dotnet/coreclr#2  0xb2244a80 in ValueNumStore::GetConstantBoundInfo(unsigned int, ValueNumStore::ConstantBoundInfo*) () from /opt/home/owner/0714r/libclrjit.so [valuenum.cpp:2871]
dotnet/coreclr#3  0xb2232492 in RangeCheck::MergeEdgeAssertions(GenTree*, unsigned int*, Range*) () from /opt/home/owner/0714r/libclrjit.so [rangecheck.cpp:588]
dotnet/coreclr#4  0xb2232f52 in RangeCheck::ComputeRange(BasicBlock*, GenTree*, GenTree*, SimplerHashTable<GenTree*, PtrKeyFuncs<GenTree>, BasicBlock*, JitSimplerHashBehavior>*, bool) () from /opt/home/owner/0714r/libclrjit.so
dotnet/coreclr#5  0xb2231d9a in RangeCheck::GetRange(BasicBlock*, GenTree*, GenTree*, SimplerHashTable<GenTree*, PtrKeyFuncs<GenTree>, BasicBlock*, JitSimplerHashBehavior>*, bool) () from /opt/home/owner/0714r/libclrjit.so
dotnet/coreclr#6  0xb223306a in RangeCheck::ComputeRange(BasicBlock*, GenTree*, GenTree*, SimplerHashTable<GenTree*, PtrKeyFuncs<GenTree>, BasicBlock*, JitSimplerHashBehavior>*, bool) () from /opt/home/owner/0714r/libclrjit.so
dotnet/coreclr#7  0xb2231d9a in RangeCheck::GetRange(BasicBlock*, GenTree*, GenTree*, SimplerHashTable<GenTree*, PtrKeyFuncs<GenTree>, BasicBlock*, JitSimplerHashBehavior>*, bool) () from /opt/home/owner/0714r/libclrjit.so
dotnet/coreclr#8  0xb223293e in RangeCheck::ComputeRangeForLocalDef(BasicBlock*, GenTree*, GenTree*, SimplerHashTable<GenTree*, PtrKeyFuncs<GenTree>, BasicBlock*, JitSimplerHashBehavior>*, bool) () from /opt/home/owner/0714r/libclrjit.so
dotnet/coreclr#9  0xb2232f38 in RangeCheck::ComputeRange(BasicBlock*, GenTree*, GenTree*, SimplerHashTable<GenTree*, PtrKeyFuncs<GenTree>, BasicBlock*, JitSimplerHashBehavior>*, bool) () from /opt/home/owner/0714r/libclrjit.so
dotnet/coreclr#10 0xb2231d9a in RangeCheck::GetRange(BasicBlock*, GenTree*, GenTree*, SimplerHashTable<GenTree*, PtrKeyFuncs<GenTree>, BasicBlock*, JitSimplerHashBehavior>*, bool) () from /opt/home/owner/0714r/libclrjit.so
dotnet/coreclr#11 0xb2231c98 in RangeCheck::OptimizeRangeCheck(BasicBlock*, GenTree*, GenTree*) () from /opt/home/owner/0714r/libclrjit.so
dotnet/coreclr#12 0xb223326e in RangeCheck::OptimizeRangeChecks() () from /opt/home/owner/0714r/libclrjit.so
dotnet/coreclr#13 0xb21dc2aa in Compiler::compCompile(void**, unsigned int*, CORJIT_FLAGS*) () from /opt/home/owner/0714r/libclrjit.so
...

[wateret]

This happens after 36efe1f. And this commit is not related to range anlaysis at all.
The backtrace shows the error is from range analysis phase but I don't think it is actual problematic place. What do you think? @papaslavik

% This problem only occurs for coreclr-release and TC-release

[papaslavik]

@wateret so does it only happen after the commit, and does it happen only on softfp? I should have a look, although it's weird it's a release version...

[papaslavik]

cannot get running release system yet...

[papaslavik]

@mkborg builds everything for release, but corerun crashes very early at any input.
It crashes in code related to tls.

[papaslavik]

now we were able to do that

[papaslavik]

Though both TC versions release and debug are crashing to me.

[papaslavik]

@wateret do you have a generally stable release version in which the test fails just in case both of the TC and coreclr are release? And that it happens only after the commit 36efe1f ?

We can build the release version only with O1 right now, and we have crashes for both release and debug versions of the test.
And the crash occurs even for the commit 4ec1a49 preceding 36efe1f

[papaslavik]

The crashes are also different from what you showed:

#0  0xb6771444 in ?? () from /usr/lib/arm-linux-gnueabi/libunwind-arm.so.8
dotnet/coreclr#1  0xb6771b00 in _Uarm_is_signal_frame () from /usr/lib/arm-linux-gnueabi/libunwind-arm.so.8
dotnet/coreclr#2  0xb6a76d34 in PAL_VirtualUnwind () from /home/krivtsov/v.nikolaev/coreoverlay/libcoreclr.so
dotnet/coreclr#3  0xb6a76f7c in RtlpRaiseException(_EXCEPTION_RECORD*) () from /home/krivtsov/v.nikolaev/coreoverlay/libcoreclr.so
dotnet/coreclr#4  0xb6a76f48 in RaiseException () from /home/krivtsov/v.nikolaev/coreoverlay/libcoreclr.so
dotnet/coreclr#5  0xb6876108 in RaiseTheExceptionInternalOnly(Object*, int, int)::$_1::operator()(RaiseTheExceptionInternalOnly(Object*, int, int)::Param*) const () from /home/krivtsov/v.nikolaev/coreoverlay/libcoreclr.so
dotnet/coreclr#6  0xb6875f84 in RaiseTheExceptionInternalOnly(Object*, int, int) () from /home/krivtsov/v.nikolaev/coreoverlay/libcoreclr.so
dotnet/coreclr#7  0xb6876688 in UnwindAndContinueRethrowHelperAfterCatch(Frame*, Exception*) () from /home/krivtsov/v.nikolaev/coreoverlay/libcoreclr.so
dotnet/coreclr#8  0xb68f7e44 in JIT_RngChkFail() () from /home/krivtsov/v.nikolaev/coreoverlay/libcoreclr.so
dotnet/coreclr#9  0xb20ed532 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[papaslavik]

@Dmitri-Botcharnikov

[papaslavik]

So, to make sure I tried the clang3.6 provided here
https://github.com/dotnet/coreclr/blob/master/Documentation/building/linux-instructions.md#how-to-enable--o3-optimization-level-for-armlinux

and built on the newest commit 4ec1a49 in release mode (with -O3) and didn't encounter any issues with the test.

I also tried it on the commit 36efe1f and it didn't have issues as well.

As for clang3.8 the issue occured in release version with -O1 for both debug and release versions of the b07369.exe and also it was present even before the commit 36efe1f

[papaslavik]

Perhaps I downloaded a different version of the exe... but it was claimed to be the newest release at the moment

[wateret]

@papaslavik
Here's how I build coreclr-release.

1. clang3.6 vanilla
2. optimization level changed - O3 to O1
3. test were built from coreclr source that is 2-3 weeks older than now. IMHO, this does not matter.

So I'll try clang3.6 patch you mentioned. However I don't think 4ec1a49 precedes 36efe1f. It is merged yesterday, isn't it?

[wateret]

/cc @parjong