cmd/pprof: redundant TMPDIRs

[dsnet]

Using go1.7beta2

The pprof tool has at least two TMPDIRs:

• One that it can take from $PPROF_TMPDIR, and defaults to $HOME/pprof. As far as I can tell, this directory is only ever used when pprof is operating remotely. This pprof directory is never deleted after it is used. So if pprof is used locally, it keeps generating empty pprof directories in a user $HOME directory and never cleans them up.
• The other temporary directory, it generates on the fly when it needs to invoke some type of visualizer for HTML, SVG, GIF, etc... pprof now properly cleans this directory up.

Why have two different variations of TMPDIRs? Why doesn't pprof clean itself up?

[rsc]

I believe the idea behind $HOME/pprof was to save profiles for future reference. If everything written there is being deleted by pprof when it exits, that kind of defeats the point and I agree that either we should just not use that directory or else we should not delete those profiles from it.

/cc @rauls5382

[rauls5382]

Yes, the idea behind $HOME/pprof is to save profiles retrieved over http and save them for future reference. pprof does not delete them so that you can examine them in the future.

The other temp directory is used to store actual temporary files, for example to communicate with dot or other tools. This directory is cleaned up when pprof exits.

I think this is working as intended.

[dsnet]

Yes, the idea behind $HOME/pprof is to save profiles retrieved over http and save them for future reference.

If that's the case, I would argue that $HOME/pprof only be generated when pprof is invoked when retrieving the profile over HTTP, rather than in all uses of pprof. In other words, only create $HOME/pprof when you about to use it.

[rauls5382]

I agree. I'll clean this up on the upstream pprof.

[rauls5382]

I have fixed this upstream: google/pprof#45
We will pick this up on the pprof sync, as per #16184