Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upcmd/compile: possible infinite recursion in Type.cmp #19869
Labels
Milestone
Comments
This comment has been minimized.
This comment has been minimized.
|
CL https://golang.org/cl/39710 mentions this issue. |
This comment has been minimized.
This comment has been minimized.
|
We need a "Sisypheanterfaces" label. |
gopherbot
pushed a commit
that referenced
this issue
Apr 6, 2017
typenamesym is called from three places: typename, ngotype, and Type.Symbol. Only in typename do we actually need a Node. ngotype and Type.Symbol require only a Sym. And writing the newly created Node to Sym.Def is unsafe in a concurrent backend. Rather than use a mutex protect to Sym.Def, make typenamesym not touch Sym.Def. The assignment to Sym.Def was serving a second purpose, namely to prevent duplicate entries on signatlist. Preserve that functionality by switching signatlist to a map. This in turn requires that we sort signatlist when exporting it, to preserve reproducibility. We'd like to use Type.cmp for sorting, but that causes infinite recursion at the moment; see #19869. For now, use Type.LongString as the sort key, which is a complete description of the type. Type.LongString is relatively expensive, but we calculate it only once per type, and signatlist is generally fairly small, so the performance impact is minimal. Updates #15756 name old alloc/op new alloc/op delta Template 39.4MB ± 0% 39.4MB ± 0% ~ (p=0.222 n=5+5) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.151 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% ~ (p=0.095 n=5+5) SSA 1.25GB ± 0% 1.25GB ± 0% +0.04% (p=0.008 n=5+5) Flate 25.3MB ± 0% 25.4MB ± 0% ~ (p=0.056 n=5+5) GoParser 31.8MB ± 0% 31.8MB ± 0% ~ (p=0.310 n=5+5) Reflect 78.3MB ± 0% 78.3MB ± 0% ~ (p=0.690 n=5+5) Tar 26.7MB ± 0% 26.7MB ± 0% ~ (p=0.548 n=5+5) XML 42.2MB ± 0% 42.2MB ± 0% ~ (p=0.222 n=5+5) name old allocs/op new allocs/op delta Template 387k ± 0% 388k ± 0% ~ (p=0.056 n=5+5) Unicode 320k ± 0% 321k ± 0% +0.32% (p=0.032 n=5+5) GoTypes 1.14M ± 0% 1.15M ± 0% ~ (p=0.095 n=5+5) SSA 9.70M ± 0% 9.72M ± 0% +0.18% (p=0.008 n=5+5) Flate 234k ± 0% 235k ± 0% +0.60% (p=0.008 n=5+5) GoParser 317k ± 0% 317k ± 0% ~ (p=1.000 n=5+5) Reflect 982k ± 0% 983k ± 0% ~ (p=0.841 n=5+5) Tar 252k ± 1% 252k ± 0% ~ (p=0.310 n=5+5) XML 393k ± 0% 392k ± 0% ~ (p=0.548 n=5+5) Change-Id: I53a3b95d19cf1a7b7511a94fba896706addf84fb Reviewed-on: https://go-review.googlesource.com/39710 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
lparth
added a commit
to lparth/go
that referenced
this issue
Apr 13, 2017
typenamesym is called from three places: typename, ngotype, and Type.Symbol. Only in typename do we actually need a Node. ngotype and Type.Symbol require only a Sym. And writing the newly created Node to Sym.Def is unsafe in a concurrent backend. Rather than use a mutex protect to Sym.Def, make typenamesym not touch Sym.Def. The assignment to Sym.Def was serving a second purpose, namely to prevent duplicate entries on signatlist. Preserve that functionality by switching signatlist to a map. This in turn requires that we sort signatlist when exporting it, to preserve reproducibility. We'd like to use Type.cmp for sorting, but that causes infinite recursion at the moment; see golang#19869. For now, use Type.LongString as the sort key, which is a complete description of the type. Type.LongString is relatively expensive, but we calculate it only once per type, and signatlist is generally fairly small, so the performance impact is minimal. Updates golang#15756 name old alloc/op new alloc/op delta Template 39.4MB ± 0% 39.4MB ± 0% ~ (p=0.222 n=5+5) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.151 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% ~ (p=0.095 n=5+5) SSA 1.25GB ± 0% 1.25GB ± 0% +0.04% (p=0.008 n=5+5) Flate 25.3MB ± 0% 25.4MB ± 0% ~ (p=0.056 n=5+5) GoParser 31.8MB ± 0% 31.8MB ± 0% ~ (p=0.310 n=5+5) Reflect 78.3MB ± 0% 78.3MB ± 0% ~ (p=0.690 n=5+5) Tar 26.7MB ± 0% 26.7MB ± 0% ~ (p=0.548 n=5+5) XML 42.2MB ± 0% 42.2MB ± 0% ~ (p=0.222 n=5+5) name old allocs/op new allocs/op delta Template 387k ± 0% 388k ± 0% ~ (p=0.056 n=5+5) Unicode 320k ± 0% 321k ± 0% +0.32% (p=0.032 n=5+5) GoTypes 1.14M ± 0% 1.15M ± 0% ~ (p=0.095 n=5+5) SSA 9.70M ± 0% 9.72M ± 0% +0.18% (p=0.008 n=5+5) Flate 234k ± 0% 235k ± 0% +0.60% (p=0.008 n=5+5) GoParser 317k ± 0% 317k ± 0% ~ (p=1.000 n=5+5) Reflect 982k ± 0% 983k ± 0% ~ (p=0.841 n=5+5) Tar 252k ± 1% 252k ± 0% ~ (p=0.310 n=5+5) XML 393k ± 0% 392k ± 0% ~ (p=0.548 n=5+5) Change-Id: I53a3b95d19cf1a7b7511a94fba896706addf84fb Reviewed-on: https://go-review.googlesource.com/39710 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If two of the types in fixedbugs/bug398.go make it into the backend and get passed to Type.cmp, they can cause infinite recursion. See https://go-review.googlesource.com/c/39710/ patch set 3 for a roundabout example.
It is non-obvious how to fix this, because if we detect infinite recursion, how should the types compare?