Each iteration the pfx is getting bigger hence you are always allocating a slightly bigger string.

See the code here https://play.golang.org/p/rZrJrrrgL4F

Each iteration the pfx is getting bigger hence you are always allocating a slightly bigger string.

See the code here https://play.golang.org/p/rZrJrrrgL4F

Oh……you are right ! I made another mistake.

Can you help me to see why the memory is leak in #34463 and the core code is in https://play.golang.org/p/o0cEeZ7o7xl and https://play.golang.org/p/o0cEeZ7o7xl

I made a mistake in demo, is not the same as the running one, the leak really confused me.

Tanks a lot

GitHub issues should be used for tracking bugs and proposals only. If you wish for help with debugging move the discussion to a more appropriate place.

• https://github.com/golang/go/wiki/Questions
• https://github.com/golang/go/wiki#the-go-community.

@egonelbre
Oh no, I really think there is some leaking there, but I'm can not reproduce it in a simple code. My production environment is leaking every day.

I'll have another try latter.

@szyhf indeed there could be a leak, but it could be in many places. It could be in the code you posted, it could be in any of the third-party libraries (bingo, ormer, database driver), some other code. Indeed it could be in Go runtime as well, but it is unlikely.

The goal is to isolate the leak - such that it clearly demonstrates where the leak is. Community sites are much better for this rather than Go language issues.

@egonelbre Thanks, I'll try to reproduce it in a clear way

BTW, the reason why I think there is a leak of strings.Builder is due to the pprof of heap shows that the Builder.WriteString() hold a lots.