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.

Sign up for GitHub

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

Jump to bottom

runtime: spurious cgo dynamic check failure on darwin/amd64 #17160

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

runtime: spurious cgo dynamic check failure on darwin/amd64 #17160

crawshaw opened this issue Sep 19, 2016 · 7 comments
Labels
FrozenDueToAge

Comments

@crawshaw
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

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

@ianlancetaylor
Copy link
Member

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

@crawshaw
Copy link
Member Author

crawshaw commented Sep 19, 2016 •
edited
Loading

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
Copy link
Contributor

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

@crawshaw
Copy link
Member Author

crawshaw commented Sep 22, 2016 •
edited
Loading

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

@crawshaw
Copy link
Member Author

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.

@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.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@crawshaw @ianlancetaylor @gopherbot