Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: "found pointer to free object" on windows-arm64 #49363

Closed
bcmills opened this issue Nov 4, 2021 · 7 comments
Closed

runtime: "found pointer to free object" on windows-arm64 #49363

bcmills opened this issue Nov 4, 2021 · 7 comments
Labels
arch-arm64 NeedsInvestigation OS-Windows release-blocker
Milestone

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Nov 4, 2021

greplogs --dashboard -md -l -e '(?ms)\Awindows.*found pointer to free object' --since=2021-05-01

2021-10-29T02:16:47-d6a9af8-2c7cdec/windows-arm64-10
2021-10-11T21:58:33-18fa840-d973bb1/windows-arm64-10

(CC @mknyszek)

@bcmills
Copy link
Member Author

@bcmills bcmills commented Nov 4, 2021

This crash seems sporadic, so it's not clear to me whether this is a 1.18 regression. We should probably at least figure out whether there is a memory-corruption problem on this platform before the 1.18 release.

@bcmills bcmills added this to the Go1.18 milestone Nov 4, 2021
@bcmills bcmills added the NeedsInvestigation label Nov 4, 2021
@cagedmantis
Copy link
Contributor

@cagedmantis cagedmantis commented Nov 10, 2021

/cc @ zx2c4 @bufflig Would you be able to take a look at this issue?

@bufflig
Copy link
Contributor

@bufflig bufflig commented Nov 10, 2021

I can see if I can reproduce it, but it looks like an issue that just happens to show up on windows and is actually not really windows specific. It's quite probable that someone from the runtime team proper has a higher chance of finding this problem.

@cherrymui
Copy link
Member

@cherrymui cherrymui commented Nov 11, 2021

The zombie object is at 0x40006adc30 whereas this stack is actively using it

goroutine 268 [semacquire]:
fmt.glob..func1()
	C:/workdir/go/src/fmt/print.go:132 +0x28
sync.(*Pool).Get(0x7ff7d0d79c60)
	C:/workdir/go/src/sync/pool.go:148 +0xc0
fmt.newPrinter()
	C:/workdir/go/src/fmt/print.go:137 +0x28
fmt.Sprint({0x40006adc30, 0x1, 0x1})
	C:/workdir/go/src/fmt/print.go:248 +0x2c
text/template.evalArgs({0x40006adc30?, 0x1?, 0x1?})
	C:/workdir/go/src/text/template/funcs.go:750 +0xa0
text/template.HTMLEscaper({0x40006adc30?, 0x7ff7d044ebac?, 0x1?})
	C:/workdir/go/src/text/template/funcs.go:631 +0x24
reflect.Value.call({0x7ff7d0888e80?, 0x7ff7d09d8b68?, 0x7ff7d0aa7ef8?}, {0x7ff7d091cbc1, 0x4}, {0x400083f7d0, 0x1, 0x6?})
	C:/workdir/go/src/reflect/value.go:543 +0x5c0
reflect.Value.Call({0x7ff7d0888e80?, 0x7ff7d09d8b68?, 0x400015e040?}, {0x400083f7d0, 0x1, 0x1})
	C:/workdir/go/src/reflect/value.go:339 +0x98
text/template.safeCall({0x7ff7d0888e80?, 0x7ff7d09d8b68?, 0x400015e040?}, {0x400083f7d0?, 0x7ff7d0aa7ef8?, 0x7ff7d0895d80?})
	C:/workdir/go/src/text/template/funcs.go:368 +0x68
text/template.(*state).evalCall(0x4000b4b3d8, {0x7ff7d0897f40?, 0x400015e040?, 0x2c78283267724164?}, {0x7ff7d0888e80?, 0x7ff7d09d8b68?, 0xa7d090a65757274?}, 0x1, {0x7ff7d0aa6c58?, 0x4000132ab0}, ...)

I wonder if we fail to keep something alive, possibly especially related to reflect.Value.call.

@gopherbot
Copy link

@gopherbot gopherbot commented Nov 12, 2021

Change https://golang.org/cl/363358 mentions this issue: reflect: keep pointer in aggregate-typed args live in Call

@cherrymui
Copy link
Member

@cherrymui cherrymui commented Nov 12, 2021

The CL above is likely to fix the crash in 2021-10-29T02:16:47-d6a9af8-2c7cdec/windows-arm64-10.

2021-10-11T21:58:33-18fa840-d973bb1/windows-arm64-10 doesn't contain that pattern so it may or may not be the same error.It could be a memory corruption like the other one earlier then causes the error, or it could be something else.

@gopherbot
Copy link

@gopherbot gopherbot commented Dec 3, 2021

Change https://golang.org/cl/369158 mentions this issue: [release-branch.go1.17] reflect: keep pointer in aggregate-typed args live in Call

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-arm64 NeedsInvestigation OS-Windows release-blocker
Projects
None yet
Development

No branches or pull requests

5 participants