> On 12 Mar 2020, at 13.13, Mhd Shulhan <m.shul...@gmail.com> wrote:
>
>
>> My question is any one have idea how to debug this so I can provide more
>> detailed report?
>>
>> Thank you in advance.
>
> So, I try to debug with gdb 9.1. Here is the sample of stack when the CPU
> got high,
>
> ...
> [New LWP 1885]
> [New LWP 1886]
> [New LWP 1887]
> [New LWP 1888]
> [New LWP 1889]
> ^C
> Thread 1 "XYZ" received signal SIGINT, Interrupt.
> runtime.futex () at /Users/XXX/share/go/src/runtime/sys_linux_amd64.s:568
> 568 /Users/X/share/go/src/runtime/sys_linux_amd64.s: No such file or
> directory.
> (gdb) where
> #0 runtime.futex () at /Users/XXX/share/go/src/runtime/sys_linux_amd64.s:568
> #1 0x0000000000431666 in runtime.futexsleep (addr=0xd6a3e8 <runtime.m0+328>,
> val=0, ns=-1) at /Users/XXX/share/go/src/runtime/os_linux.go:44
> #2 0x000000000040bd9f in runtime.notesleep (n=0xd6a3e8 <runtime.m0+328>) at
> /Users/XXX/share/go/src/runtime/lock_futex.go:151
> #3 0x000000000043b858 in runtime.stoplockedm () at
> /Users/XXX/share/go/src/runtime/proc.go:1972
> #4 0x000000000043d4c6 in runtime.schedule () at
> /Users/XXX/share/go/src/runtime/proc.go:2455
> #5 0x000000000043d89d in runtime.park_m (gp=0xc000166c00) at
> /Users/XXX/share/go/src/runtime/proc.go:2691
> #6 0x00000000004651fb in runtime.mcall () at
> /Users/XXX/share/go/src/runtime/asm_amd64.s:318
> #7 0x0000000000465114 in runtime.rt0_go () at
> /Users/XXX/share/go/src/runtime/asm_amd64.s:220
> #8 0x0000000000000000 in ?? ()
> ...
>
> Rebuild with `-gcflags=all="-N -l"` and running it again result in the same
> stack trace.
>
>
> Looking at git blame for each files does not shown any new commit introduced
> since after Go 1.14. Maybe others can look.
>
> The next thing I will do is bissecting and rebuild and report again.
According to my bisection, the following commit cause it,
14:18 ~/src/go
(af1f3b0082...)|BISECTING tokenomy 0 % git bisect good
98858c438016bbafd161b502a148558987aa44d5 is the first bad commit
commit 98858c438016bbafd161b502a148558987aa44d5
Author: Ian Lance Taylor <i...@golang.org>
Date: Tue Feb 25 20:23:15 2020 -0800
runtime: don't panic on racy use of timers
If we see a racy use of timers, as in concurrent calls to Timer.Reset,
do the operations in an unpredictable order, rather than crashing.
Fixes #37400
Change-Id: Idbac295df2dfd551b6d762909d5040fc532c1b34
Reviewed-on: https://go-review.googlesource.com/c/go/+/221077
Run-TryBot: Ian Lance Taylor <i...@golang.org>
TryBot-Result: Gobot Gobot <go...@golang.org>
Reviewed-by: Michael Knyszek <mknys...@google.com>
src/runtime/time.go | 216 ++++++++++++++++----------------------------------
src/time/time_test.go | 40 ++++++----
2 files changed, 92 insertions(+), 164 deletions(-)
Link to CL: https://go-review.googlesource.com/c/go/+/221077
If anyone have any idea the minimal test code to test it on my VM, I will test
it.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/282D59C4-D154-4B8A-862D-77EDCA999750%40gmail.com.
