Comment 1:

This looks like a dup of issue #353. Calling foo(b) stores b in a temporary variable that
won't be cleared until the function returns, and it until it does, the reference is
findable on the stack. Inlining definitly exacerbates this, because without inlining
there wouldn't be a separate slot for the copy of the variable, so calling the channel
runtime would smash the pointers on the stack from the call to foo. The only sure-fire
way to drop the references to pointers on the stack is to let the goroutine exit.
I'll try to think of some way to help this case.

Comment 2:

I've confirmed that changing the foo(b) function to not be inlinable fixes the leak:
func foo(b buffer) {
        bar()
}
var x int
func bar() {
        x++
}

Comment 3:

Yes, the inlining matters because it effectively turns foo(b) into {tmp := b; /* body of
foo */} and then that temporary variable is still on the goroutine's main stack frame
for the rest of the loop. Only another call to foo would clear it.

Comment 4:

Yeah, I followed that part.  I was just making sure it could be worked around in code if
needed.  Unfortunately the real program in question is a bit more gnarly and I'm not
even sure which call is making the temporary, if my problem is even this bug.
How much work would it be to turn foo(b) into { tmp := b; /* body of foo */; tmp =
buffer{} } ?

Comment 5:

Came to reply to an email and got distracted and went exploring in gc.  As expected,
there are lots of data structures and conventions to learn.
In any case, the attached doesn't work, but you get the point.  I think the Nodes I
actually need to OAS[2] to N are in tinlvar(t) that are assigned in the OAS2 block
above, and probably after inlsubstlist but before the OGOTO?
</exploring>

Comment 6:

Er, didn't attach.

Attachments:

1. x.patch (1595 bytes)

Comment 7:

If i understand correctly, this also happens for any code that is explicitly written to
keep a pointer in a temporary, and a more fundamental fix would be to zero out any
pointers on the stack as they leave scope.  
escape analysis computes a 'loopdepth' for every variable, which comes close.  we could
insert a zeroing OAS for pointer typed variables at the end of their loops, that would
benefit everyone.
but if the problem is only bad for inlining, i can probably make x.patch work, i'll look
closer this afternoon.

Comment 8:

This is in fact a dup of 353.

Status changed to Duplicate.

Merged into issue #353.