runtime: 1.11rc2 crash in runtime.sigInitIgnored #27183
Description
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.11rc2 darwin/386
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
GOBIN=""
GOCACHE="/Users/joe/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/joe/go:/Users/joe/src/repo004/GOPATH"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.10.3/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.10.3/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/mg/q2kh762j0bb2fbtpj1fh7_0h0000gn/T/go-build454742149=/tmp/go-build -gno-record-gcc-switches -fno-common"```
What did you do?
Our application links against a shared library that's written in Go. When compiling with both Go 1.11 RC1 and 1.11 RC2 we're seeing a crash at start for one of our 32-bit applications. The strange thing is that the crash depends on how the application is launched. If it's launched via the command line we see no crash. If it's launched via a call for a parent application, it crashes. We have no issues with Go 1.10. The issue happens without any calls to the go library, and seems like it's doing the runtime initialization. We don't see this issue with the 64-bit application.
I suspect that this crash is related to the TLS changes made in b3a854c.
Here's the crash in lldb
libbbtgo.dylib`runtime.sigInitIgnored:
0x24df180 <+0>: mov ecx, dword ptr gs:[0x18]
-> 0x24df187 <+7>: cmp esp, dword ptr [ecx + 0x8]
0x24df18a <+10>: jbe 0x24df1ce ; <+78>
0x24df18c <+12>: sub esp, 0x8
0x24df18f <+15>: mov eax, dword ptr [0x2d91eac]
0x24df195 <+21>: mov ecx, dword ptr [esp + 0xc]
0x24df199 <+25>: mov edx, ecx
0x24df19b <+27>: shr ecx, 0x5
0x24df19e <+30>: cmp ecx, 0x1
0x24df1a1 <+33>: jae 0x24df1c7 ; <+71>
0x24df1a3 <+35>: lea ebx, [0x2d91eac]
0x24df1a9 <+41>: lea ebx, [ebx + 4*ecx]
0x24df1ac <+44>: mov dword ptr [esp], ebx
0x24df1af <+47>: mov ecx, edx
0x24df1b1 <+49>: mov ebx, 0x1
0x24df1b6 <+54>: shl ebx, cl
0x24df1b8 <+56>: or eax, ebx
0x24df1ba <+58>: mov dword ptr [esp + 0x4], eax
0x24df1be <+62>: call 0x24a7560 ; runtime/internal/atomic.Store
0x24df1c3 <+67>: add esp, 0x8
0x24df1c6 <+70>: ret
0x24df1c7 <+71>: call 0x24cab80 ; runtime.panicindex
0x24df1cc <+76>: ud2
0x24df1ce <+78>: call 0x24f1280 ; runtime.morestack_noctxt
0x24df1d3 <+83>: jmp 0x24df180 ; <+0>
0x24df1d5 <+85>: int3
0x24df1d6 <+86>: int3
0x24df1d7 <+87>: int3
0x24df1d8 <+88>: int3
0x24df1d9 <+89>: int3
0x24df1da <+90>: int3
0x24df1db <+91>: int3
0x24df1dc <+92>: int3
0x24df1dd <+93>: int3
0x24df1de <+94>: int3
0x24df1df <+95>: int3
(lldb) register read
General Purpose Registers:
eax = 0x00000019
ebx = 0xbfffd710
ecx = 0x00000000
edx = 0x00000001
edi = 0xbfffd728
esi = 0x00000000
ebp = 0x00000000
esp = 0xbfffd728
ss = 0x00000023
eflags = 0x00210246 diskprocessor`DiskProcessorShellBase.DeleteProcessTempFiles%%o<DiskProcessorShellBase> + 600
eip = 0x024df187 libbbtgo.dylib`runtime.sigInitIgnored + 7
cs = 0x0000001b
ds = 0x00000023
es = 0x00000023
fs = 0x00000000
gs = 0x0000000f
As you can see, gs:[0x18] contains a null pointer, which causes a segfault on the next instruction