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: spurious cgo dynamic check failure on darwin/amd64 #17160

Closed
crawshaw opened this issue Sep 19, 2016 · 7 comments

Comments

Projects
None yet
3 participants
@crawshaw
Copy link
Contributor

commented Sep 19, 2016

On darwin/amd64, several uses of C.free(unsafe.Pointer(cstr)) in plugin/plugin_dlopen.go get caught incorrectly on the dynamic cgo check:

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

goroutine 1 [running]:
panic(0x40b85c0, 0xc42000c280)
    /Users/crawshaw/go/src/runtime/panic.go:496 +0x1a0
plugin._cgoCheckPointer0(0x4303550, 0x0, 0x0, 0x0, 0x1)
    plugin/_obj/_cgo_gotypes.go:41 +0x59
plugin.open(0x40cff89, 0x7, 0x0, 0x0, 0x0)
    /Users/crawshaw/go/src/plugin/plugin_dlopen.go:106 +0x828
plugin.Open(0x40cff89, 0xa, 0x403e78e, 0xc42000c208, 0xc42000c200)
    /Users/crawshaw/go/src/plugin/plugin.go:28 +0x35
main.main()
    /Users/crawshaw/go/misc/cgo/testplugin/src/host/host.go:24 +0x5c

Calling a C helper function, C.freestr(cstr), does not get caught.

I spent a while trying to isolate a test case, but no luck. Once I've mailed the darwin plugin CLs, replacing C.freestr with C.free shows the error consistently when running misc/cgo/testplugin.

/cc @ianlancetaylor

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Sep 19, 2016

The usual false positive with the tests is passing a pointer to a field in a struct such that cgo does not recognize that you are passing just a pointer to a field, and the runtime examines the whole struct, not just the field, for Go pointers.

@crawshaw

This comment has been minimized.

Copy link
Contributor Author

commented Sep 19, 2016

No struct fields here, just *C.char objects created either with C.CString or returned from C.realpath (which was created with malloc).

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Sep 19, 2016

I would need to see a test case. I am not aware of any false positives such as you describe.

@crawshaw

This comment has been minimized.

Copy link
Contributor Author

commented Sep 19, 2016

All I have is plugin/plugin_dlopen.go after the CL series ending in https://golang.org/cl/29393 minus the changes in https://golang.org/c/29392. My attempts to isolate it failed.

@gopherbot

This comment has been minimized.

Copy link

commented Sep 19, 2016

CL https://golang.org/cl/29392 mentions this issue.

@crawshaw

This comment has been minimized.

Copy link
Contributor Author

commented Sep 22, 2016

I believe I've found the problem, it's in my darwin plugin CL series not the cgo check. Working on a fix.

@crawshaw

This comment has been minimized.

Copy link
Contributor Author

commented Sep 23, 2016

Patch set 3 of CL 29394 addresses this.

When I opened this bug I had written off dlopen being the cause because the stack trace pointed to the first C.free in the function. Of course that C.free was in a defer, so it happened after the dlopen. For some reason it took me a while to see that.

@crawshaw crawshaw closed this Sep 23, 2016

@golang golang locked and limited conversation to collaborators Sep 23, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.