Thanks for reporting. No explicit GOAMD64=v.. value is set during the build, which should use a baseline of v1. I had a look at the build log and there's evidence of x86-64-v4 support being enabled explicitly.
Go may probe CPU features at runtime and pick the optimized code for specific instruction set support, which is why you would observe AVX* instructions in objdump, even though the specific code path is not activated at runtime. If the backtrace is to be trusted, it point somewhere around this place: https://github.com/golang/go/blob/d90b98e65320778f3b1f99a6951ab20f04d218b3/src/crypto/internal/fips140/ecdsa/ecdsa.go#L140-L158 which, should it fail, it would fail during early init(), where variable values are initialized. However, what is puzzling is why the problem went away after a reboot? The only explanation I see is that either CPUID reporting was wrong (unlikely?), or something else changed. Is this a VM with -cpu host perhaps? ** Changed in: snapd (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2155805 Title: snap commands crash with SIGILL on x86-64-v3 CPUs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/2155805/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
