runtime: Consul process crash, and gdb pointing to Go code

[rohitjun]

$ go version
1.10.3

###Does this issue reproduce with the latest release?
I have not checked if the problem is seen with latest version.

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

Linux, ARM 32.

What did you do?

The consul process crashes when there was nothing going on in the node and gdb points to below :

• 1 LWP 6836 0x000539f8 in runtime.sigtrampgo (ctx=0x12f23d10, info=0x12f23c90, sig=17)
  at /repo/rcsci2/ee-sstate-esekilx5339-3/rcs-yocto/make/build/build_dusx2_rcs-rootfs/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/arm-wrs-linux-gnueabi/go/src/runtime/signal_unix.go:305
  (gdb) print/x *g
  $1 = {stack = {lo = 0x0, hi = 0x0}, stackguard0 = 0x0, stackguard1 = 0x0, _panic = 0x0, _defer = 0x0, m = 0x0, sched = {sp = 0x0, pc = 0x0, g = 0x0, ctxt = 0x0, ret = 0x0, lr = 0x0, bp = 0x0}, syscallsp = 0x0, syscallpc = 0x0, stktopsp = 0x0, param = 0x0,
  atomicstatus = 0x0, stackLock = 0x0, goid = 0x0, waitsince = 0x0, waitreason = 0x0 "", schedlink = 0x0, preempt = 0x0, paniconfault = 0x0, preemptscan = 0x0, gcscandone = 0x0, gcscanvalid = 0x0, throwsplit = 0x0, raceignore = 0x0, sysblocktraced = 0x0,
  sysexitticks = 0x0, traceseq = 0x0, tracelastp = 0x0, lockedm = 0x0, sig = 0x0, writebuf = {array = 0x0, len = 0x0, cap = 0x0}, sigcode0 = 0x0, sigcode1 = 0x0, sigpc = 0x0, gopc = 0x0, startpc = 0x0, racectx = 0x0, waiting = 0x0, cgoCtxt = {array = 0x0, len = 0x0,
  cap = 0x0}, labels = 0x0, timer = 0x0, selectDone = 0x0, gcAssistBytes = 0x0}
  (gdb)

Thanks for help.

[julieqiu]

Hi @rohitjun - would you be able to provide more info about this issue, including a code example of what you were running and if you can reproduce this on the latest version of Go?

[rohitjun]

thanks for your answer. We actually using hashicorp product named as "consul" and go lang is supported lib for consul. And during the time when crash happens, nothing unusual is happening and the system is relax state with no load.
We have not tried latest go lang revision but if we know that there is relation of this fault to go revision hat we use, then we could definately uplift (slow process to uplift 3pp revisions). and also fault is not easily reproducable.

[julieqiu]

It seems like you are looking for advice on a hashicorp product, rather than reporting a bug with the Go Go tools and standard library. A better place would be to ask this question on a forum, rather than this issue tracker. See https://golang.org/wiki/Questions.

[andybons]

We need more information. The line about sigtrampgo is simply saying that the process got a SIGCHLD. Can you provide the full output after you continue in the debugger?