SIGILL: illegal instruction when making cgo call

[martin.o...@gmail.com]

Hello,

Encountered this issue running a statically compiled binary that uses cgo (Compiled using go1.8.3). It works OK on one CPU type but not on another. The binary is built on a server which is neither of the two below. Is this a Go issue or something to do with how the C library is built (gcc version mismatch, compiler flags etc.)?  

SIGILL: illegal instruction

PC=0x1283c22 m=0 sigcode=2

signal arrived during cgo execution

goroutine 1 [syscall, locked to thread]:

runtime.cgocall(0x11a2c80, 0xc4219e9c70, 0x4e7e960)

/usr/local/go/src/runtime/cgocall.go:131 +0xe2 fp=0xc4219e9c30 sp=0xc4219e9bf0

xxx-wv._Cfunc_d2v_init(0x4e7e9a0, 0x4e7e9d0, 0xc, 0x4e7e960, 0x0, 0x0)

/tmp/go-build684597318/xxx-wv/_obj/_cgo_gotypes.go:137 +0x4e fp=0xc4219e9c70 sp=0xc4219e9c30

xxx-wv.NewFromFile(0xc430df8fc0, 0x26, 0xc430df9170, 0x26, 0x101, 0x0, 0x0, 0x0, 0x0, 0x1000000000005, ...)

/home/ubuntu/go/src/xxx-wv/wv.go:100 +0xe5 fp=0xc4219e9cf0 sp=0xc4219e9c70

xxx-ent.init.1()

/home/ubuntu/go/src/xxx-ent/ent.go:132 +0x425 fp=0xc4219e9ef0 sp=0xc4219e9cf0

xxx-ent.init()

/home/ubuntu/go/src/xxx-ent/util.go:109 +0x2cc fp=0xc4219e9f68 sp=0xc4219e9ef0

xxx-api.init()

/home/ubuntu/go/src/xxx-api/s.go:203 +0x89 fp=0xc4219e9f78 sp=0xc4219e9f68

main.init()

/home/ubuntu/go/src/xxx.go:122 +0x8e fp=0xc4219e9f88 sp=0xc4219e9f78

runtime.main()

/usr/local/go/src/runtime/proc.go:173 +0x1ca fp=0xc4219e9fe0 sp=0xc4219e9f88

runtime.goexit()

/usr/local/go/src/runtime/asm_amd64.s:2197 +0x1 fp=0xc4219e9fe8 sp=0xc4219e9fe0

goroutine 17 [syscall, locked to thread]:

runtime.goexit()

/usr/local/go/src/runtime/asm_amd64.s:2197 +0x1

goroutine 20 [syscall]:

os/signal.signal_recv(0x0)

/usr/local/go/src/runtime/sigqueue.go:116 +0x104

os/signal.loop()

/usr/local/go/src/os/signal/signal_unix.go:22 +0x22

created by os/signal.init.1

/usr/local/go/src/os/signal/signal_unix.go:28 +0x41

rax    0x4e7f130

rbx    0x7fff1a258190

rcx    0x7fff1a257e18

rdx    0x0 

rdi    0x7fff1a257e20

rsi    0x1283e2a

rbp    0x7fff1a2581b8

rsp    0x7fff1a257e20

r8     0x1283e2a

r9     0x7fff1a257a50

r10    0x301fdb0

r11    0x1283e2a

r12    0x4e7f130

r13    0x4e7f150

r14    0x7fff1a257e50

r15    0x7fff1a257fe0

rip    0x1283c22

rflags 0x10206

cs     0x33

fs     0x0 

gs     0x0 

Architecture for the server that doesn't work:

processor    : 7
vendor_id    : GenuineIntel
cpu family    : 6
model        : 44
model name    : Intel(R) Xeon(R) CPU           X5680  @ 3.33GHz
stepping    : 2
microcode    : 0x15
cpu MHz        : 3325.000
cache size    : 12288 KB
physical id    : 1
siblings    : 4
core id        : 3
cpu cores    : 4
apicid        : 7
initial apicid    : 7
fpu        : yes
fpu_exception    : yes
cpuid level    : 11
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm ida arat dtherm
bogomips    : 6650.00
clflush size    : 64
cache_alignment    : 64
address sizes    : 40 bits physical, 48 bits virtual
power management:

The same binary works properly on a server with this architecture:

processor    : 7
vendor_id    : GenuineIntel
cpu family    : 6
model        : 45
model name    : Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
stepping    : 7
microcode    : 0x70d
cpu MHz        : 2900.000
cache size    : 20480 KB
physical id    : 1
siblings    : 4
core id        : 3
cpu cores    : 4
apicid        : 7
initial apicid    : 7
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm ida arat pln pts dtherm
bogomips    : 5800.00
clflush size    : 64
cache_alignment    : 64
address sizes    : 42 bits physical, 48 bits virtual
power management:

[Ian Lance Taylor]

On Wed, Nov 1, 2017 at 7:47 AM, <martin.o...@gmail.com> wrote:
>
> Encountered this issue running a statically compiled binary that uses cgo
> (Compiled using go1.8.3). It works OK on one CPU type but not on another.
> The binary is built on a server which is neither of the two below. Is this a
> Go issue or something to do with how the C library is built (gcc version
> mismatch, compiler flags etc.)?
>
> SIGILL: illegal instruction
> PC=0x1283c22 m=0 sigcode=2
> signal arrived during cgo execution
> goroutine 1 [syscall, locked to thread]:
> runtime.cgocall(0x11a2c80, 0xc4219e9c70, 0x4e7e960)
> /usr/local/go/src/runtime/cgocall.go:131 +0xe2 fp=0xc4219e9c30
> sp=0xc4219e9bf0

The error occurred while executing C code, so this is more likely to
be a problem with how your C library is built. You should be able to
use gdb to see the exact instruction at address 0x1283c22, and to see
which function it is in.

Ian