Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: segment fault at the runtime.lock2 #52060

Closed
hawkingrei opened this issue Mar 31, 2022 · 3 comments
Closed

runtime: segment fault at the runtime.lock2 #52060

hawkingrei opened this issue Mar 31, 2022 · 3 comments
Labels
WaitingForInfo

Comments

@hawkingrei
Copy link

@hawkingrei hawkingrei commented Mar 31, 2022

What version of Go are you using (go version)?

$ go version

go version go1.18 linux/amd64

and it can be reproduced in the go1.16 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
➜  ~ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1874664808=/tmp/go-build -gno-record-gcc-switches"

What did you do?

git clone https://github.com/pingcap/tidb.git
cd tidb
make ut

What did you expect to see?

not segment fault

What did you see instead?

There is a certain probability to report segment fault.

then we check the coredump. it will report like this.

(gdb) bt
#0  runtime.lock2 (l=0x5c257d8 <runtime.sched+24>) at /home/genius/project/go/src/runtime/lock_futex.go:53
#1  0x000000000129d465 in runtime.lockWithRank (l=<optimized out>, rank=<optimized out>) at /home/genius/project/go/src/runtime/lockrank_off.go:22
#2  runtime.lock (l=<optimized out>) at /home/genius/project/go/src/runtime/lock_futex.go:47
#3  runtime.mexit (osStack=true) at /home/genius/project/go/src/runtime/proc.go:1535
#4  0x000000000129d129 in runtime.mstart0 () at /home/genius/project/go/src/runtime/proc.go:1385
#5  0x00000000012c9b85 in runtime.mstart () at /home/genius/project/go/src/runtime/asm_amd64.s:367
#6  0x000000000329a86d in crosscall_amd64 () at gcc_amd64.S:40
#7  0x00007f0115979fc0 in ?? ()
#8  0x00007fffe409bfa0 in ?? ()
#9  0x00007fffe409be9f in ?? ()
#10 0x000000c000003860 in ?? ()
#11 0x00000000012c9b80 in ?? ()
#12 0x0000000000000000 in ?? ()


50      func lock2(l *mutex) {
51              gp := getg()
52
53              if gp.m.locks < 0 {
54                      throw("runtime·lock: lock count")
55              }
56              gp.m.locks++
57
(gdb) p gp
$1 = (runtime.g *) 0xc000003860
(gdb) p gp.m
$2 = (runtime.m *) 0x0

so why is it 0x0?

@mengzhuo
Copy link
Contributor

@mengzhuo mengzhuo commented Apr 1, 2022

cc @cherrymui @thanm

@cherrymui
Copy link
Member

@cherrymui cherrymui commented Apr 5, 2022

Is this failure reproducible? Does it happen with other program? Could you check your C (and unsafe, if any) uses are correct? Have you run the race detector?

Could you share the full stack trace produced by Go? Thanks.

@cherrymui cherrymui added the WaitingForInfo label Apr 5, 2022
@gopherbot
Copy link

@gopherbot gopherbot commented May 5, 2022

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
WaitingForInfo
Projects
None yet
Development

No branches or pull requests

4 participants