The same problem occurs again with the same error message. The pstack result:
> Thread 1 (process 12230): > #0 runtime.futex () at /usr/local/go/src/runtime/sys_linux_amd64.s:439 > #1 0x00000000004293f2 in runtime.futexsleep (addr=0x1b0a950 > <runtime.m0+272>, val=0, ns=-1) at /usr/local/go/src/runtime/os_linux.go:45 > #2 0x000000000040f9ab in runtime.notesleep (n=0x1b0a950 <runtime.m0+272>) > at /usr/local/go/src/runtime/lock_futex.go:151 > #3 0x00000000004315f5 in runtime.stopm () at > /usr/local/go/src/runtime/proc.go:1680 > #4 0x00000000004327d2 in runtime.findrunnable (gp=0x45cbd1 > <runtime.goexit+1>, inheritTime=false) at > /usr/local/go/src/runtime/proc.go:2135 > #5 0x000000000043328c in runtime.schedule () at > /usr/local/go/src/runtime/proc.go:2255 > #6 0x00000000004335a6 in runtime.park_m (gp=0xca01842780) at > /usr/local/go/src/runtime/proc.go:2318 > #7 0x0000000000459ffb in runtime.mcall () at > /usr/local/go/src/runtime/asm_amd64.s:286 > #8 0x0000000001b0a100 in ?? () > #9 0x00007ffdc5be26e0 in ?? () > #10 0x0000000001b0a100 in ?? () > #11 0x00007ffdc5be26d0 in ?? () > #12 0x0000000000430544 in runtime.mstart () at > /usr/local/go/src/runtime/proc.go:1152 > #13 0x0000000000459ec1 in runtime.rt0_go () at > /usr/local/go/src/runtime/asm_amd64.s:186 > #14 0x000000000000000a in ?? () > #15 0x00007ffdc5be2718 in ?? () > #16 0x000000000000000a in ?? () > #17 0x00007ffdc5be2718 in ?? () > #18 0x0000000000000000 in ?? () > On Sunday, January 7, 2018 at 7:52:00 PM UTC+8, she...@pingcap.com wrote: > > We enable race detection in the test environment and disable it when > building to be published binaries. > I double checked the building environment to make sure the race detection > is disabled. For we care the performance very much. > > On Saturday, January 6, 2018 at 7:04:09 PM UTC+8, Dave Cheney wrote: >> >> You can still check for races if you build your production binary with >> -race and deploy it as normal. There will be a some performance hit so you >> probably shouldn't do this for all your binaries, but it will be a cheap >> way to flush out any data races in your code. >> >> On Saturday, 6 January 2018 21:15:56 UTC+11, she...@pingcap.com wrote: >>> >>> Thanks for your advice! I got the error message and the pstack result >>> screenshot from one of our client. I will try to use some OCR tools to >>> convert the image to text next time. >>> >>> For the questions: >>> 1. The binary is built without race detector flag. I have checked it. >>> 2. We do not use cgo. I will check if there is any unsafe package. >>> >>> Unfortunately, I can not reproduce this problem. This is the first time >>> and the only time I meet it. >>> >>> Thanks! >>> >>> On Saturday, January 6, 2018 at 1:28:24 AM UTC+8, Ian Lance Taylor wrote: >>>> >>>> On Fri, Jan 5, 2018 at 7:17 AM, <she...@pingcap.com> wrote: >>>> > >>>> > I meet a strange problem when running a program on Linux. I get >>>> "fatal: >>>> > morestack on g0" from stderr. The process is still there but does not >>>> > respond anymore. When I use `curl >>>> > http://ip:port/debug/pprof/goroutine?debug=1` to check the stack, but >>>> it >>>> > halts. There is nothing useful in stderr or dmesg. >>>> >>>> (I would like to encourage you and everyone else to not post >>>> screenshots of text. Just include the text in the e-mail message as >>>> text. Screenshots of images, sure, but not text. Thanks.) >>>> >>>> The error "fatal: morestack on g0" should, of course, never happen. >>>> The first questions are standard: have you run your program with the >>>> race detector? Do you use cgo or the unsafe package? >>>> >>>> Beyond that, does the problem happen consistently? Is there a way >>>> that we can reproduce it? >>>> >>>> Ian >>>> >>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
