cmd/pprof: forces choice between "inuse" and "alloc" heap profiles

[rhysh]

Hello! I've got a bug with go tool pprof's proto format that forces a choice between "inuse" and "alloc" modes (assuming "inuse" by default), which means I've got to capture two separate profiles or use the standalone google/pprof tool.

1. What version of Go are you using (go version)?

   $ go version
   go version devel +8f3c8a3 Fri Aug 26 20:06:58 2016 +0000 darwin/amd64
   $ go1.7 version
   go version go1.7 darwin/amd64
   

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

   darwin/amd64, though I've also observed this on linux/amd64.

3. What did you do?

   First, I run a trivial http server with pprof enabled. Then I point go tool pprof at it, asking the command to save a gzipped-protobuf-formatted heap profile. I then try to read that profile in various modes: inuse_space and alloc_space

4. What did you expect to see?

   I expected a single saved heap profile to be readable in all four modes (inuse_space, inuse_objects, alloc_space, alloc_objects). I expected this because the other pprof tool can do this, and because the text file served from /debug/pprof/heap can be interpreted in all four modes.

5. What did you see instead?

   A heap profile saved with go tool pprof -proto -inuse_space -output ./file http://... cannot be read with go tool pprof -alloc_space ./file, and vice versa.

main.go:

package main

import (
    "net/http"
    _ "net/http/pprof"
)

var sink []byte

func main() {
    for i := 0; i < 10; i++ {
        sink = make([]byte, 1<<20)
    }
    panic(http.ListenAndServe("127.0.0.1:8080", nil))
}

test.sh:

#!/usr/bin/env bash

go version

go build -o ./server ./main.go
./server &
server="$!"
sleep 1

for tool in "go tool pprof" "pprof"; do
    for record_style in "" "-inuse_space" "-alloc_space"; do
        $tool $record_style -proto -symbolize=remote -output ./heap.pb.gz http://127.0.0.1:8080/debug/pprof/heap &>/dev/null
        for view_style in "-inuse_space" "-alloc_space"; do
            $tool $view_style -top ./heap.pb.gz &>/dev/null || printf "failed tool=%q record=%q view=%q\n" "$tool" "$record_style" "$view_style"
        done
        rm ./heap.pb.gz
    done
done

kill -KILL -- "$server"
rm ./server

$ ./test.sh 
go version devel +8f3c8a3 Fri Aug 26 20:06:58 2016 +0000 darwin/amd64
failed tool=go\ tool\ pprof record='' view=-alloc_space
failed tool=go\ tool\ pprof record=-inuse_space view=-alloc_space
failed tool=go\ tool\ pprof record=-alloc_space view=-inuse_space
$ PATH="$HOME/go1.7/bin:$PATH" ./test.sh 
go version go1.7 darwin/amd64
failed tool=go\ tool\ pprof record='' view=-alloc_space
failed tool=go\ tool\ pprof record=-inuse_space view=-alloc_space
failed tool=go\ tool\ pprof record=-alloc_space view=-inuse_space

[aclements]

/cc @rauls5382

[rauls5382]

I agree this is a problem. Earlier versions of pprof would select between alloc/inuse before saving the profile on a proto. That was later changed to save all the data in the proto.

go tool pprof is based on an older version of pprof, which does not have that fix. At some point we will refresh the tool to use the new version. I already have that in my queue under #16184

In the meantime, I recommend using the standalone pprof to collect the profiles.

[quentinmit]

Closing as dupe of #16184

[rsc]

@rauls5382, we are probably not going to sync upstream pprof into pprof for Go 1.8 - too late. But we may still get to generating the binary pprof format by default from Go's profile handlers. Was the bug that discarded data in the legacy->binary conversion or was it still in binary->binary saving? If it's just in legacy->binary, then we can ignore it assuming we get direct binary generation working. If it's in the binary->binary saving too then we might want to grab that specific change. Thanks.

[rsc]

Let's call this a dup of #17764.

It looks like the initial checkin to github.com/google/pprof has a very different copy of profile/legacy_profile.go, so I can't find out when the fix in question was committed or what it was. That said, let's just work on getting the binary form generated, which will solve this problem.