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

cmd/cgo: spurious pointer check for pointer to int struct field #30245

Closed
winglq opened this issue Feb 15, 2019 · 4 comments
Closed

cmd/cgo: spurious pointer check for pointer to int struct field #30245

winglq opened this issue Feb 15, 2019 · 4 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@winglq
Copy link

winglq commented Feb 15, 2019

What version of Go are you using (go version)?

$ go version
go version go1.9.2 linux/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOHOSTARCH="amd64"
GOHOSTOS="linux"

What did you do?

I understand the rule Go code may pass a Go pointer to C provided the Go memory to which it points does not contain any Go pointers. But something wired happened while I pass parameters to C functions.

Code example 1 & 2 are sample codes for the problem.

In the code example 1 I passed &f.a to the C function and go runtime captured cgo argument has Go pointer to Go pointer error. I think no go pointers is in f.a.

And in code example 2 I changed attribute a to a point and the code could run peacefully.

I didn't see any big differences between example 1 and 2. Why code exapmle 1 panic?

// code exapmle 1
1   package main
  1
  2 /*
  3 #include <stdio.h>
  4
  5 void nothing(void *x) {
  6 }
  7 */
  8 import "C"
  9 import (
 10         "unsafe"
 11 )
 12
 13 type foo struct {
 14         p *int
 15         a int
 16 }
 17
 18 func main() {
 19         f := &foo{}
 20         b := 10
 21         f.p = &b
 22         f.a = b
 23         C.nothing(unsafe.Pointer(&f.a))
 24 }
// code exapmle 2
1   package main
  1
  2 /*
  3 #include <stdio.h>
  4
  5 void nothing(void *x) {
  6 }
  7 */
  8 import "C"
  9 import (
 10         "unsafe"
 11 )
 12
 13 type foo struct {
 14         p *int
 15         a *int
 16 }
 17
 18 func main() {
 19         f := &foo{}
 20         b := 10
 21         f.p = &b
 22         f.a = &b
 23         C.nothing(unsafe.Pointer(f.a))
 24 }

What did you expect to see?

example 1 and example 2 have the same result

What did you see instead?

output of code example 1:

panic: runtime error: cgo argument has Go pointer to Go pointer

goroutine 1 [running]:
main.main.func1(0xc420010038)
        /root/go/src/github.com/winglq/test/pointer/main.go:23 +0x96
main.main()
        /root/go/src/github.com/winglq/test/pointer/main.go:24 +0x7f

example 2 is ok.

@bcmills
Copy link
Contributor

bcmills commented Feb 15, 2019

This looks like a bug in the pointer check. Per https://golang.org/cmd/cgo/#hdr-Passing_pointers:

When passing a pointer to a field in a struct, the Go memory in question is the memory occupied by the field, not the entire struct.

CC @ianlancetaylor @hirochachacha

@bcmills bcmills changed the title Panic happened while passing int pointer to cgo function cmd/cgo: spurious pointer check for pointer to int struct field Feb 15, 2019
@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 15, 2019
@hirochachacha
Copy link
Contributor

It is reproducible on go1.11 darwin/amd64, but it isn't reproducible on tip darwin/amd64

@ianlancetaylor
Copy link
Member

Thanks. I believe that this is fixed in 1.12 (to not report an error for example 1) by the fix for #14210.

@winglq
Copy link
Author

winglq commented Feb 19, 2019

Thanks.

@golang golang locked and limited conversation to collaborators Feb 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants