Skip to content

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

Closed

Description

@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.

Activity

  1. added
    priority: p1Important issue which blocks shipping the next release. Will be fixed prior to next release.
    api: cloudprofilerIssues related to the Cloud Profiler API.
    on May 7, 2018
  2. aalexand commented on May 7, 2018

    @aalexand
    Contributor

    @jqll FYI

  3. willie commented on May 7, 2018

    @willie
    Author

    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.

  4. aalexand commented on May 7, 2018

    @aalexand
    Contributor

    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.

  5. willie commented on May 7, 2018

    @willie
    Author

    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?)

  6. willie commented on May 8, 2018

    @willie
    Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

api: cloudprofilerIssues related to the Cloud Profiler API.priority: p1Important issue which blocks shipping the next release. Will be fixed prior to next release.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    ⌂ Proxy