panic: runtime error: cgo argument has Go pointer to Go pointer #30626
Comments
What version of Go are you using ( go version )?
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using ( go env )?
What did you do?
I am trying to use opencv in go, my code doesn’t work.
////////
func CreateImage(w, h, depth, channels int) *IplImage <
size := C.cvSize(C.int(w), C.int(h))
img := C.cvCreateImage(size, C.int(depth), C.int(channels))
return (*IplImage)(img)
>
What did you expect to see?
I expect «cvFillPoly» function can work correctly.
What did you see instead?
panic: runtime error: cgo argument has Go pointer to Go pointer
goroutine 1 [running]:
The text was updated successfully, but these errors were encountered:
Please fill in the rest of the issue template.
You need to make sure you understand the cgo documentation in order to make this work properly. It has a section dedicated to this: https://golang.org/cmd/cgo/#hdr-Passing_pointers
If I search online for the error message in the title I can find examples of other people encountering this sort of issue, it is likely you will find help elsewhere.
It seems likely that the go-pointer-to-go-pointer lives inside your dst variable.
Failing that, if there is still a problem, please provide a complete reproducer, otherwise it is very difficult for anyone to help.
Timed out in state WaitingForInfo. Closing.
(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)
Footer
© 2023 GitHub, Inc.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
panic in gl «cgo argument has Go pointer to Go pointer» #200
Comments
about a year ago i started getting this sort of thing;
found out it was due to a strictness increase, and have been using «GODEBUG=cgocheck=0» to avoid.
didn’t report because i thought it was a general issue that would have to be sorted in the fullness of time.
reporting now because it bit me, i forgot the hack, and i then noticed #156.
The text was updated successfully, but these errors were encountered:
What version of Go are you using? Show output of go version .
Do you have the latest commit gl repository?
This is something we fixed a while ago (see go-gl/gl#31), so I wanna check if you’re using old stuff or latest stuff.
Also, why did you post this issue in glfw repo, when the panic seems to be in gl repo?
What version of Go are you using? Show output of go version.
currently, 1.6.2, but originally, 1.6.1, i think, and also have tried 1.8.(1/2/3)
Do you have the latest commit gl repository?
i did a fresh update to my installed go packages, glfw and gl, before reporting, using ‘go get -u’
if it helps — i find this in gl/package.go;
// Generated based on the OpenGL XML specification:
// SVN revision 27695
(i also updated glfw lib from 3.12 to 3.21, but this was for other reasons not related to this.)
Also, why did you post this issue in glfw repo, when the panic seems to be in gl repo?
sorry, yes, since i cant really use them separately, i just lazily conflated them mentally. i can re-report if that helps?
cmd/cgo: []byte argument has Go pointer to Go pointer #28606
Comments
With Go 1.11 and HEAD: go version devel +a2a3dd00c9 Thu Sep 13 09:52:57 2018 +0000 darwin/amd64 , the following program:
I suspect (but cannot yet show that) this is related to the fact that gzip.Writer is passing a []byte to the Write method made out of an array field of the gzip.Writer struct.
The text was updated successfully, but these errors were encountered:
cgo isn’t clever enough to look at where the arguments are coming from. It should work if you write it as
Hi @ianlancetaylor . Is this something that does not need to be addressed anymore? If so, can we close the issue. If not, I would love to pick it up as a first issue
As far as I know, this still happens. The program above still fails in the same way.
If you want to look at this, that would be great. But I want to caution you that I don’t think this will be easy to fix. At the moment I don’t really see how to fix it at all.
Awesome. I’m delighted to investigate it and try some options. Reproducing it first..
@ianlancetaylor sorry I have been unavailable for a while due to some unforeseen circumstances.
Up until now,
- I tested out the code and confirmed behaviour
- I have gone through the unsafe documentation as well as the gzip documentation.
I observed a note during pointer conversion that said
That would explain why this is able to work just fine as you mentioned earlier when the expressions are combined.
What I intend to do within the next 3 days
- Go through the cgo documentation and implementation.
I would love to also look at how the type conversion is implemented. Can you point me in any direction of where this is? Thanks
The relevant code here is cmd/cgo/gcc.go, around the method rewriteCall .
I don’t think there is going to be any simple fix here. I think that fixing this will require a significant change to how the cgo tool works.
Footer
© 2023 GitHub, Inc.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
cmd/cgo: false ‘cgo argument has Go pointer to Go pointer when using Go 1.6’ report #13934
Comments
It seems that the Go runtime reports an error, stating:
The offending code is
As seen from a bug report for zmq4, the author didn’t get the runtime panic when running the same code using Go 1.6
Go version: 1.6 beta1
OS/Platform: Ubuntu 15.10 linux/amd64
The text was updated successfully, but these errors were encountered:
Do I assume correctly that atfter a call to
the data variable contains the value
Please set the environment variable GOTRACEBACK=2 and show us the full stack trace.
Actually, I suspect this is fixed by https://golang.org/cl/18391, which I think was not in Go 1.6 beta1. Can you try tip?
It’s the same using tip:
GOTRACEBACK=2 go run test.go
It really looks for all the world like you are still running the old code somehow.
Please try this program on the version of go you have crashing:
The code above produces the following output:
I did a git pull on the go source tree and recompiled:
And repeated my previous failing test and the results are the same, the program panics.
What version of the github.com/pebbe/zmq4 package are you using? The line numbers don’t correspond to the code I see when I go get github.com/pebbe/zmq4 .
I use the master branch (commit 1c9da3d). I use git subtree for dependency management in my project and don’t use go get .
This line in your stack trace:
corresponds to the second call to _cgoCheckPointer0 in this code in generated by cmd/cgo:
But that does not make sense, as the stack trace shows that the value d is being passed as an empty slice, when we can see from the earlier call in the stack trace, and from the fact that the code did not panic, that the slice is not empty.
cmd/cgo: cgo pointer checking panic on address of slice from function call #14210
Comments
Testing our code on go 1.6rc1 I ran into an unexpected cgo pointer check panic calling a write-like C function.
The case is reproducible using the following code:
My expectation was that they would run the same. But the crash function panics while the ok function does not. The different between them is that in ok I first assign the buf.Bytes() return value to a temporary variable, instead of calling the C function with the return value directly.
Go version: go1.6rc1 linux/amd64 binary download from golang.org
Steps to reproduce: go run code.go crash
Expected result: Hello, cgo! written on stdout
Actual result: panic: runtime error: cgo argument has Go pointer to Go pointer
The text was updated successfully, but these errors were encountered:
That is the way the current implementation works, a consequence of the way that cgo rewrites calls to C functions. We can try to do better for 1.7, but we aren’t going to change this for 1.6.
To be clear, what is happening is that the expression &buf.Bytes()[0] is too complex for cgo to pull apart, so the pointer that cgo is checking is not just the slice returned by buf.Bytes() but the entire object that buf.Bytes() points to. As it happens, that object is buf itself, because the slice is actually a pointer into an internal array. And that object has internal pointers, because of the slice. So it’s kind of circular and unfortunate.
If the slice didn’t point back into buf, then it would work. For example, this variant works.