text/template: leaks goroutines on errors

[dvyukov]

The following program leaves a hanged goroutine. If a server reloads templates on the fly, this behavior can leads to unbounded number of leaked goroutines.

package main

import (
    "html/template"
    "time"
)

func main() {
    template.New("foo").Parse("{{.")
    time.Sleep(time.Second)
    panic("who's there?")
}

panic: who's there?

goroutine 1 [running]:
main.main()
    /tmp/htmltempl.go:11 +0x297

goroutine 5 [chan send]:
text/template/parse.(*lexer).errorf(0xc2080c2000, 0x5d8290, 0xf, 0x0, 0x0, 0x0, 0xffffff01)
    src/text/template/parse/lex.go:165 +0xca
text/template/parse.lexInsideAction(0xc2080c2000, 0x623b78)
    src/text/template/parse/lex.go:280 +0xaf7
text/template/parse.(*lexer).run(0xc2080c2000)
    src/text/template/parse/lex.go:198 +0x5d
created by text/template/parse.lex
    src/text/template/parse/lex.go:191 +0x1b9

on commit ccc76db

[rambocoder]

@dvyukov how did you know to panic and look at the stack trace for a goroutine stuck on the send channel? go-fuzz seems to be about testing if the error happens inside of the API call by looking for a panic or a wrong error output, this is a very interesting twist to also see if a goroutine is leaked.

[dvyukov]

@rambocoder I noticed it accidentally. Since I reuse the same process for thousands of tests, lots of crash reports contained thousands of lexer goroutines in the dump.
I am not sure how reliably detect goroutine leaks, since APIs are generally allowed to create some amount of background goroutines. I guess it is possible to use some heuristic. But I would wait for at least a second such case first.

[dvyukov]

@rambocoder But of course in your own Fuzz function you are free to call runtime.NumGoroutine and panic if the number increases.

[gravis]

Duplicates #10574

[mdempsky]

Closing as duplicate.