--alloc_space tells you about what functions allocated the most over the lifetime of your program, even if that memory got garbage collected. It's normal to see bcrypt show up there.

To debug a leak you want to use --inuse_space on a profile captured during execution.

Hi @FiloSottile

using --inuse_space:

(pprof) top --inuse_space
Ignore expression matched no samples
Showing nodes accounting for 335.58s, 98.17% of 341.83s total
Dropped 624 nodes (cum <= 1.71s)
Showing top 10 nodes out of 64
      flat  flat%   sum%        cum   cum%
   290.58s 85.01% 85.01%    290.58s 85.01%  github.com/----/----/vendor/golang.org/x/crypto/blowfish.encryptBlock /Users/henriquechehad/go/src/github.com/----/----/vendor/golang.org/x/crypto/blowfish/block.go
    13.58s  3.97% 88.98%     13.58s  3.97%  runtime.duffcopy /usr/local/go/src/runtime/duff_amd64.s
    11.85s  3.47% 92.45%    302.34s 88.45%  github.com/----/----/vendor/golang.org/x/crypto/blowfish.ExpandKey /Users/henriquechehad/go/src/github.com/----/----/vendor/golang.org/x/crypto/blowfish/block.go
     5.71s  1.67% 94.12%      5.71s  1.67%  runtime.mach_semaphore_signal /usr/local/go/src/runtime/sys_darwin_amd64.s
     5.03s  1.47% 95.59%      5.03s  1.47%  runtime.usleep /usr/local/go/src/runtime/sys_darwin_amd64.s
     4.39s  1.28% 96.87%      4.77s  1.40%  syscall.Syscall /usr/local/go/src/syscall/asm_darwin_amd64.s
     4.14s  1.21% 98.08%      4.14s  1.21%  runtime.memclrNoHeapPointers /usr/local/go/src/runtime/memclr_amd64.s
     0.21s 0.061% 98.15%    306.85s 89.77%  github.com/----/----/vendor/golang.org/x/crypto/bcrypt.CompareHashAndPassword /Users/henriquechehad/go/src/github.com/----/----/vendor/golang.org/x/crypto/bcrypt/bcrypt.go
     0.06s 0.018% 98.16%      4.68s  1.37%  runtime.mallocgc /usr/local/go/src/runtime/malloc.go
     0.03s 0.0088% 98.17%      2.38s   0.7%  runtime.findrunnable /usr/local/go/src/runtime/proc.go

To make it easier for us to reproduce your results, can you try writing up standalone code that we can run? Obviously, we don't want your code to include actual passwords from your production environment. (I wasn't able to reproduce your results, but maybe your usage pattern is affecting memory usage.)

If you write it in the form of a benchmark, you can run go test -bench=. -memprofile mem.out to create a memory profile and then run go tool pprof mem.out

@meirf I tried two ways to reproduce, one with the code in a main(), compiling and using pkg/profile. The other with benchmark. The first way I could reproduce but not with the second.

1. https://gist.github.com/henriquechehad/3692a2818670881252608fd788b68243
2. https://gist.github.com/henriquechehad/c66191032423c2927654c1bd760d2caa

https://gist.github.com/henriquechehad/3692a2818670881252608fd788b68243
https://gist.github.com/henriquechehad/c66191032423c2927654c1bd760d2caa

I don't see proof of any problem from these gists. The first link shows NewSaltedCipher is allocating some memory and if you run list NewSaltedCipher you'll see it attributed to var result Cipher which is expected since Cipher takes up about 4KB. If you put runtime.GC() at the end of main, you'll see that the memory drops way down which makes me think that there is no leak or that the GC isn't running when you need it to. Regarding the second link, I recommend this to get better acquainted with go benchmarks.

Also, now that I look more closely at your pprof output above I notice the unit is time instead of space so I think you were running pprof on a cpu profile instead of a memory profile. Time can impact space - if there's not enough time, there might not be enough time to gc, but I don't think that's what you intended in your output.

Thanks for the clarification @meirf and @FiloSottile. It's not the issue then. Appreciate your help.