Go: cmd/cgo: jmethodID/jfieldID is not mapped to uintptr if building with the Android NDK [1.15 backport]
@randall77 requested issue #40954 to be considered for backport to the next 1.15 minor release.
@gopherbot please open a backport issue for 1.15.
gopherbot
All 24 comments
This issue prevents Go programs from running correctly on Android 11 (random, but somewhat reliable crashing).
I'm proposing we just backport to 1.15. Although this is a problem in earlier releases as well, we can require 1.15 for Android 11 support, which was just released.
randall77
on 16 Sep 2020
Change https://golang.org/cl/255318 mentions this issue: cmd/compile: make Haspointers a method instead of a function
gopherbot
on 16 Sep 2020
Change https://golang.org/cl/255320 mentions this issue: cmd/compile: don't allow go:notinheap on the heap or stack
gopherbot
on 16 Sep 2020
Change https://golang.org/cl/255337 mentions this issue: cmd/compile: allow aliases to go:notinheap types
gopherbot
on 16 Sep 2020
Change https://golang.org/cl/255321 mentions this issue: cmd/cgo: use go:notinheap for anonymous structs
gopherbot
on 16 Sep 2020
Change https://golang.org/cl/255338 mentions this issue: cmd/compile: make go:notinheap error message friendlier for cgo
gopherbot
on 16 Sep 2020
The stack for this issue broke the x/perf tests via github.com/mattn/go-sqlite3 (CC @mattn):
https://build.golang.org/log/b3355d5757dfbd59df196f50ba5039883d208d44
# github.com/mattn/go-sqlite3
../../../../pkg/mod/github.com/mattn/[email protected]/callback.go:101:6: type callbackArgRaw must be go:notinheap
FAIL golang.org/x/perf/storage/app [build failed]
bcmills
on 17 Sep 2020
Hmm, but the failure is at head, and this issue is a 1.15 backport. I'll open a new issue.
bcmills
on 17 Sep 2020
Change https://golang.org/cl/255637 mentions this issue: cmd/compile: propagate go:notinheap implicitly
gopherbot
on 17 Sep 2020
Change https://golang.org/cl/255697 mentions this issue: cmd/compile: propagate go:notinheap implicitly
gopherbot
on 17 Sep 2020
Gentle ping. I hope this backport can make the Go 1.15.3 release.
eliasnaur
on 24 Sep 2020
@eliasnaur We are looking into balancing the complexity of the changes, and hopefully will weigh in soon. I'm sorry for the delay and lack of comments, but I want you to know that we are actively discussing this.
toothrot
on 24 Sep 2020
I've read over all the CLs and I'm happy with them. The one outstanding concern, I believe, is whether this breaks any existing cgo-using code. The tip commits are currently working their way through global testing inside Google. If they pass that without introducing new build failures, then I'm good with the cherry-pick.
aclements
on 24 Sep 2020
We’re going to run tests on our internal corpus of code before we proceed. That should happen by next week, but no promises :) /cc @neild
andybons
on 2 Oct 2020
Change https://golang.org/cl/259300 mentions this issue: [release-branch.go1.15] cmd/compile: export notinheap annotation to object file
gopherbot
on 3 Oct 2020
The tip commits are currently working their way through global testing inside Google. If they pass that without introducing new build failures, then I'm good with the cherry-pick.
For (my) reference, the tip commit hashes that correspond to the backport CLs are (latest on top):
- a9c75ecd3da2d87ce08b2e75bd4f332185cd7fc8 - cmd/compile: export notinheap annotation to object file (newly added; see https://github.com/golang/go/issues/41766#issuecomment-702997336)
- 22053790fa2c0944df53ea95df476ad2f855424f - cmd/compile: propagate go:notinheap implicitly
- 37f261010f837f945eaa2d33d90cd822b4e93459 - cmd/compile: make go:notinheap error message friendlier for cgo
- 42b023d7b9cb8229e3035fa3d36bce41a1ef0c43 - cmd/cgo: use go:notinheap for anonymous structs
- 4f915911e84819b69329a224d5b646983ac9fed7 - cmd/compile: allow aliases to go:notinheap types
- d9a6bdf7ef4d0dd15608427b0f7ba3c45c221a3c - cmd/compile: don't allow go:notinheap on the heap or stack
- 623652e73fa694eacac9e4b93049817615f1be1d - cmd/compile: make Haspointers a method instead of a function
- c0602603b20186228b4f89f265cb3f7665e06768 - runtime: implement StorepNoWB for wasm in assembly (newly added; see CL comment)
dmitshur
on 6 Oct 2020
The global testing inside Google has completed and no new issues were identified connected to the aforementioned commits.
Approving for Go 1.15 per discussion in a release meeting, this is a serious issue without a workaround where we needed to balance multiple factors going into the decision.
dmitshur
on 8 Oct 2020
Change https://golang.org/cl/260878 mentions this issue: runtime: implement StorepNoWB for wasm in assembly
gopherbot
on 9 Oct 2020
Change https://golang.org/cl/260878 mentions this issue: [release-branch.go1.15] runtime: implement StorepNoWB for wasm in assembly
gopherbot
on 9 Oct 2020
Closed by merging 0b80775b8fb2f08d0cb9a673f13eb30ec17372d3 to release-branch.go1.15.
gopherbot
on 9 Oct 2020
There's one more CL in the stack that needs to be submitted before this is fully resolved. Reopening to track that.
dmitshur
on 9 Oct 2020
Closed by merging cfeb16ddec5b2134198dcc029cdd501ed11a7c01 to release-branch.go1.15.
gopherbot
on 9 Oct 2020
Closed by merging 76a2c87a2c4e78f40f0f70bda3da93c773630179 to release-branch.go1.15.
dmitshur
on 12 Oct 2020
The one outstanding concern, I believe, is whether this breaks any existing cgo-using code.
I'm afraid it did break something, see https://github.com/golang/go/issues/42032.
aykevl
on 17 Oct 2020
Related issues
go101
·
3Comments
myitcv
·
3Comments
rakyll
·
3Comments
stub42
·
3Comments
ajstarks
·
3Comments
Most helpful comment
@eliasnaur We are looking into balancing the complexity of the changes, and hopefully will weigh in soon. I'm sorry for the delay and lack of comments, but I want you to know that we are actively discussing this.