runtime: Illegal Instruction segfault in libcoreclr.so on CPU without AVX

I have not found any requirements about the CPU so I assume that this is a bug.

I have an ASP .NET Core 2 application running on an PC with an Intel N3450 CPU that does not support AVX. The application seems to work fine but crashes when a view containing the following HTML fragment is displayed.

<p class="field control has-icon">
    <input class="input" asp-for="Username" placeholder="Benutzername" >
    <span class="icon is-small"><i class="fa fa-user"></i></span>
    <span asp-validation-for="Username" class="help is-danger"></span>
</p>

When that part (and the other inputs) are removed from the view, then it can be displayed.

Attaching Visual Studio to the process I was able to obtain the following disassembly where it complained about an illegal vinsertf128 instruction. This page http://www.felixcloutier.com/x86/VINSERTF128.html tells me that it is an AVX instruction.

0x00007efdbafca90e  je     0x7efdbafca9b4
0x00007efdbafca914  vinsertf128 $0x1,0x300(%rdi),%ymm0,%ymm0 <--- Illegal Instruction
0x00007efdbafca91e  vinsertf128 $0x1,0x310(%rdi),%ymm1,%ymm1
0x00007efdbafca928  vinsertf128 $0x1,0x320(%rdi),%ymm2,%ymm2
0x00007efdbafca932  vinsertf128 $0x1,0x330(%rdi),%ymm3,%ymm3
0x00007efdbafca93c  vinsertf128 $0x1,0x340(%rdi),%ymm4,%ymm4
0x00007efdbafca946  vinsertf128 $0x1,0x350(%rdi),%ymm5,%ymm5
0x00007efdbafca950  vinsertf128 $0x1,0x360(%rdi),%ymm6,%ymm6
0x00007efdbafca95a  vinsertf128 $0x1,0x370(%rdi),%ymm7,%ymm7
0x00007efdbafca964  vinsertf128 $0x1,0x380(%rdi),%ymm8,%ymm8
0x00007efdbafca96e  vinsertf128 $0x1,0x390(%rdi),%ymm9,%ymm9
0x00007efdbafca978  vinsertf128 $0x1,0x3a0(%rdi),%ymm10,%ymm10
0x00007efdbafca982  vinsertf128 $0x1,0x3b0(%rdi),%ymm11,%ymm11
0x00007efdbafca98c  vinsertf128 $0x1,0x3c0(%rdi),%ymm12,%ymm12
0x00007efdbafca996  vinsertf128 $0x1,0x3d0(%rdi),%ymm13,%ymm13
0x00007efdbafca9a0  vinsertf128 $0x1,0x3e0(%rdi),%ymm14,%ymm14
0x00007efdbafca9aa  vinsertf128 $0x1,0x3f0(%rdi),%ymm15,%ymm15
0x00007efdbafca9b4  testb  $0x1,0x30(%rdi)

This looks to be the following code fragment: https://github.com/dotnet/coreclr/blob/master/src/pal/src/arch/amd64/context2.S#L144

Error from dmesg: [65504.474506] traps: dotnet[7146] trap invalid opcode ip:7fec90c76914 sp:7fec76ff6af0 error:0

Is this really a bug or it is currently expected that CPUs without AVX will cause problems? Can I compile the coreclr myself to work around the issue until there is a fix? I’m happy to provide more information if needed.

dotnet --info

.NET Command Line Tools (2.1.4)

Product Information:
 Version:            2.1.4
 Commit SHA-1 hash:  5e8add2190

Runtime Environment:
 OS Name:     debian
 OS Version:  9
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.4/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.5
  Build    : fdf361624c1087ec874615382781754392e69118

/proc/cpuinfo

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 92
model name	: Intel(R) Celeron(R) CPU N3450 @ 1.10GHz
stepping	: 9
microcode	: 0x18
cpu MHz		: 799.957
cache size	: 1024 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 21
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm 3dnowprefetch intel_pt kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust smep erms mpx rdseed smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts
bugs		:
bogomips	: 2188.80
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 24 (13 by maintainers)

Most upvoted comments

@tannergooding that would not help, the problem was in PAL and it detects ymm registers presence from the structure passed in by the kernel. The rare thing with this processor is that it has extended state, but that doesn’t contain ymm registers. I don’t have access to such device.