runtime: encountering SIGILL in 1.4, 1.4.1

[wwwtyro]

I do not see this issue with 1.2.1.

After compiling and running, I see the following fault:

SIGILL: illegal instruction
PC=0x510010

Inspecting the issue w/ gdb:

(gdb) x/4i $pc
=> 0x510010 <github.com/control-center/serviced/commons/docker.(*Image).Tag+256>:   (bad)  
   0x510011 <github.com/control-center/serviced/commons/docker.(*Image).Tag+257>:   
    jo     0x510014 <github.com/control-center/serviced/commons/docker.(*Image).Tag+260>
   0x510013 <github.com/control-center/serviced/commons/docker.(*Image).Tag+259>:   add    %al,(%rax)
   0x510015 <github.com/control-center/serviced/commons/docker.(*Image).Tag+261>:   retq   

Note (bad) @0x510010

I also disassembled with objdump -dS for comparison. Here's the relevant portion:

if err != nil {
  50ffe7:   48 83 f8 00             cmp    $0x0,%rax
  50ffeb:   48 89 44 24 70          mov    %rax,0x70(%rsp)
  50fff0:   74 24                   je     510016 <github.com/control-center/serviced/commons/docker.(*Image).Tag+0x106>
        return nil, err
  50fff2:   48 c7 84 24 90 01 00    movq   $0x0,0x190(%rsp)
  50fff9:   00 00 00 00 00 
  50fffe:   48 89 84 24 98 01 00    mov    %rax,0x198(%rsp)
  510005:   00 
  510006:   48 89 8c 24 a0 01 00    mov    %rcx,0x1a0(%rsp)
  51000d:   00 
  51000e:   48 81 c4 70 01 00 00    add    $0x170,%rsp
  510015:   c3                      retq   

I don't see 0x510010 here, though, so not sure how to interpret.

Any suggestions for continuing to debug this issue?

[mikioh]

First, please take a look at https://github.com/golang/go/blob/master/CONTRIBUTING.md, especially "Filing issues."

[minux]

It seems the processor jumps to the middle of one instruction.
(the instruction starts at 51000e, but somehow pc is set to
510010)

This kind of problem is difficult to diagnose remotely.
Is your program open source? Could you please produce a
minimum standalone example for this problem?

[wwwtyro]

@mikioh: thanks, here's the missing information:

$ uname -a
Linux rterrell 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                24
On-line CPU(s) list:   0-23
Thread(s) per core:    2
Core(s) per socket:    6
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 45
Stepping:              7
CPU MHz:               1200.000
BogoMIPS:              3991.51
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              15360K
NUMA node0 CPU(s):     0-5,12-17
NUMA node1 CPU(s):     6-11,18-23

@minux: Thank you; yes, working on a minimum standalone example as we type.

[wwwtyro]

I'd also like to note that it appears running with -race or -gcflags '-N' (no compiler optimization) results in this issue not occurring. Does -race disable optimization?

[minux]

No. -race doesn't disable optimization unless you also pass -gcflags -N.

[wwwtyro]

Good to know, thank you.

[davecheney]

However the race run time does introduce more calls into functions which
were previously leaves, making them ineligible for inlining.

On Tue, Feb 3, 2015 at 2:27 AM, Minux Ma notifications@github.com wrote:

No. -race doesn't disable optimization unless you also pass -gcflags -N.

—
Reply to this email directly or view it on GitHub
#9728 (comment).

[dvyukov]

inlining runs long before racewalk
racewalk should not affect inlining decisions

[davecheney]

But we have lots of code that says

if raceEnabled {
somefunction()
}

so if raceEnabled is not false, the function is no longer a leaf.

On Tue, Feb 3, 2015 at 6:41 AM, Dmitry Vyukov notifications@github.com
wrote:

inlining runs long before racewalk
racewalk should not affect inlining decisions

—
Reply to this email directly or view it on GitHub
#9728 (comment).

[dvyukov]

well, maybe
but I would expect that most of these functions in runtime that do 'if raceEnabled' are not inlinable

[minux]

if const {
someFunction()
}

won't be inlined even if const is false.

For example,
$ cat t.go
package f

const B = false

func G() {
G()
}

func F() {
if B {
G()
}
}
$ go tool 6g -m t.go
$ go tool 6g -m -l=3 t.go
$ go tool 6g -m -l=4 t.go
t.go:5: can inline G
t.go:9: can inline F
t.go:11: inlining call to G

This is a problem of the current inliner implementation, it determines
whether a func
could be inlined before constant propagation and dead code elimination.

[wwwtyro]

Problem solved: I was making improper use of the unsafe module. Closing.

[mikioh]

If possible, can you please describe a bit what is the "improper use of the unsafe package" for future reference, Thanks.

[wwwtyro]

TBH, I don't know what specifically was wrong with this before, nor why this implementation seems to work. The diff is here: https://github.com/control-center/serviced/pull/1566/files

If anyone could elucidate this for me, I'd be obliged.

[ianlancetaylor]

On GNU/Linux TIOCGPRGP returns a 4 byte value, so trying to catch it in a [2]byte argument is doomed to fail.

[wwwtyro]

Much obliged!