profiler: not collecting CPU data for Go code in a c-archive

[willie]

Client

Profiler

Describe Your Environment

Ubuntu on GKE, Go code is built with -buildmode=c-archive. C++ program is calling the built Go archive.

Expected Behavior

I expect to be able to see, for my Go code: CPU, Heap, Contention, and Threads profiles.

Actual Behavior

I see, for my Go code: Heap, Contention, and Threads profiles. The CPU profile is missing.

I know that the docs for pprof note that:

StartCPUProfile does not work by default for Go code built with -buildmode=c-archive or -buildmode=c-shared. StartCPUProfile relies on the SIGPROF signal, but that signal will be delivered to the main program's SIGPROF signal handler (if any) not to the one used by Go. To make it work, call os/signal.Notify for syscall.SIGPROF, but note that doing so may break any profiling being done by the main program.

I'm happy with those limitations. I just need to know how to turn this on in the context of using the stackdriver profiler.

[aalexand]

@jqll FYI

[willie]

After reading more about signal.Notify (and how it chains vs. replaces), I was able to remedy my immediate problem by putting this code immediately before the call to profiler.Start:

	sig := make(chan os.Signal, 1)
	signal.Notify(sig, syscall.SIGPROF)
	go func() {
		for {
			<-sig
		}
	}()

I don't know if that's the correct way or if there's some way that you want to address this in the profiler library. I just didn't realize the behavior of signal.Notify.

[aalexand]

Does the code inside of the goroutine here ever execute? I have a feeling that SIGPROF is handled by the runtime so just signal.Notify(make(chan os.Signal), syscall.SIGPROF) might be sufficient.

[willie]

Honestly, I didn't know and didn't want something to block unnecessarily, so I was being super cautious. I will change it to your code. Thanks! (Maybe this should make it into the docs as to how to properly do this for this case?)

[willie]

@aalexand Your proposed change works just fine. A lot simpler!