Re: [go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

> ... reproducible with 1.7.x. it might be worth sticking to that version Good suggestion! Oddly enough, go1.7.4 shows the same thing... [jaten@biggie no.cgo]$ ldd ./vhaline.174.nocgo not a dynamic executable [jaten@biggie no.cgo]$ go tool pprof ./vhaline.174.nocgo cpu-profile.120387

Re: [go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

You mentioned that this was reproducible with 1.7.x. it might be worth sticking to that version to avoid having to concurrently debug this external code issue. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and

Re: [go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

Yes, ldd is how I confirmed I didn't have cgo: [jaten@biggie no.cgo]$ ldd ./vhaline-5min not a dynamic executable [jaten@biggie no.cgo]$ On Tue, Feb 7, 2017 at 5:48 PM, Ian Lance Taylor wrote: > On Tue, Feb 7, 2017 at 3:08 PM, Jason E. Aten wrote: > >

Re: [go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

On Tue, Feb 7, 2017 at 3:08 PM, Jason E. Aten wrote: > On Tue, Feb 7, 2017 at 11:54 AM, Ian Lance Taylor wrote >> >> > >> > Ok. Any idea was runtime._ExternalCode means? >> >> It means that a profiling signal was received while executing code >> that was not

Re: [go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

On Tue, Feb 7, 2017 at 11:54 AM, Ian Lance Taylor wrote > > > > Ok. Any idea was runtime._ExternalCode means? > > It means that a profiling signal was received while executing code > that was not written in Go. It should only happen in a program that > uses cgo. Suprisingly,

Re: [go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

On Mon, Feb 6, 2017 at 9:53 PM, Jason E. Aten wrote: > > On Monday, February 6, 2017 at 11:49:42 PM UTC-6, Dave Cheney wrote: >> >> The give away is the frequency of the gc lines. gc 15 (the 15th gc event) >> happened at 1314 seconds into your programs execution this tells me

Re: [go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

On Tue, Feb 7, 2017 at 10:58 AM, Kale B wrote: > Go to http://localhost:6067/debug/pprof/profile with a browser/curl/etc, > it should display a more useful error message. > Thanks Kale. I got the much more useful: Could not enable CPU profiling: cpu profiling already in use

Re: [go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

Go to http://localhost:6067/debug/pprof/profile with a browser/curl/etc, it should display a more useful error message. On Tuesday, February 7, 2017 at 8:51:47 AM UTC-8, Jason E. Aten wrote: > > > > On Tue, Feb 7, 2017 at 10:38 AM, Jason E. Aten <> wrote: > >> On Tue, Feb 7, 2017 at 10:12 AM,

Re: [go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

On Tue, Feb 7, 2017 at 10:38 AM, Jason E. Aten <> wrote: > On Tue, Feb 7, 2017 at 10:12 AM, Jason E. Aten <> wrote: > >> If anyone can supply information on the mystery runtime._ExternalCode >> that would be super helpful. >> >> I'm not linking in any cgo libraries. (beyond what the runtime does

Re: [go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

On Tue, Feb 7, 2017 at 10:12 AM, Jason E. Aten wrote: > If anyone can supply information on the mystery runtime._ExternalCode that > would be super helpful. > > I'm not linking in any cgo libraries. (beyond what the runtime does > automatically for dns). Err... so actually

Re: [go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

Nice, stress.bash is indeed super simple, but finds issues that -race alone does not. Thanks for that. I'm still having the 100% cpu peg problem. I was able to observe it under go1.7.4 as well, so it's not specifically a go1.8rc3 issue. If anyone can supply information on the mystery

[go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

On Monday, February 6, 2017 at 11:55:21 PM UTC-6, Dave Cheney wrote: > > I think there are more data races in your product > Thanks for pointing that out, Dave. Fixed in latest. How were you running (what is in stress.bash?) that caused more issues that "go test -race" alone ? -- You

[go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

None whatsoever I'm afraid On Tuesday, 7 February 2017 16:53:45 UTC+11, Jason E. Aten wrote: > > > On Monday, February 6, 2017 at 11:49:42 PM UTC-6, Dave Cheney wrote: > >> The give away is the frequency of the gc lines. gc 15 (the 15th gc event) >> happened at 1314 seconds into your programs

[go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

I think there are more data races in your product http://paste.ubuntu.com/23946008/ On Tuesday, 7 February 2017 16:42:28 UTC+11, Jason E. Aten wrote: > > the race is fixed in the latest push; > a572f570c52f70c9518bc1b3e3319ff9e2424885; it was an artifact of adding > logging levels, and would

[go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

On Monday, February 6, 2017 at 11:49:42 PM UTC-6, Dave Cheney wrote: > The give away is the frequency of the gc lines. gc 15 (the 15th gc event) > happened at 1314 seconds into your programs execution this tells me that gc > is likely not your problem. If it were your terminal would be swamped

[go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

> did manage to catch the processing running away again, this time at 300%, and I got some output with gctrace=1 as you suggested. I'm not sure how to read the lines though; could you advise Dave? The give away is the frequency of the gc lines. gc 15 (the 15th gc event) happened at 1314

[go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

gc 15 @1314.779s 0%: 0.031+0.29+0.11 ms clock, 0.49+0/0.99/0.47+1.7 ms cpu, 167->167->164 MB, wow, does that actually mean a 1314 second garbage collection? holy canoly. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this

[go-nuts] Re: troubleshooting 100% cpu peg - runtime._ExternalCode ?

> Since there is nothing that changes in the processes over time, the fact that it kicks in after a few minutes makes me think it may be a garbage collection issue. Running with GODEBUG=gctrace=1 will confirm / deny this hypothesis. On Tuesday, 7 February 2017 16:06:09 UTC+11, Jason E. Aten