panic in gl "cgo argument has Go pointer to Go pointer"

[splace]

about a year ago i started getting this sort of thing;

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

goroutine 1 [running, locked to thread]:
github.com/go-gl/gl/v3.3-compatibility/gl.ShaderSource.func1(0x7fdfdeafe700, 0x100000001, 0xc42000e088, 0xc420010398)
	/home/simon/gocode/src/github.com/go-gl/gl/v3.3-compatibility/gl/package.go:25556 +0x52

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.

[dmitshur]

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?

[splace]

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?

[splace]

i also just double checked, gl's code archive was rebuilt automatically after the update.

[dmitshur]

Which of these https://godoc.org/github.com/go-gl/glfw versions are you using?

[splace]

3.2 (and tested with 3.1) both same error.

this is now with me having deleted all local go-gl and reinstalled.

[dmitshur]

Ok, so this might be a valid bug then. Can you please provide full information (what OS you're using, etc.) and a small snippet to help us reproduce this? If we can reproduce it with latest version, we should be able to fix it. Thanks for the report.

[dmitshur]

Actually, the panic is in gl.ShaderSource, I'm guessing the problem might be with how you're calling it. Post a snippet of that.

[splace]

i guess this would be where an issue might be, but i'm not seeing it:

type Shader uint32

// compile shader
// return opengl driver reference object
func MakeShader(source []byte, stype uint32) (thisShader Shader) {
	thisShader = Shader(gl.CreateShader(stype))
	stringStart:=&source[0]
	lenString := int32(len(source))
	gl.ShaderSource(uint32(thisShader), 1, &stringStart, &lenString)
	gl.CompileShader(uint32(thisShader))
.
.
.
}

[dmitshur]

That code does contain a problem. You're passing a pointer to stringStart , which is a Go pointer to Go memory source[0]. And you're getting a very appropriate error:

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

Cgo memory passing rules disallow passing a Go pointer to Go pointer as of Go 1.6. You should allocate C memory, copy the Go string in there, and pass a pointer to that.

We've created gl.Strs helper to make that process convenient and easy.

https://godoc.org/github.com/go-gl/gl/v2.1/gl#Strs

So your MakeShader code can look like this:

thisShader := gl.CreateShader(stype)

csources, free := gl.Strs(source)
gl.ShaderSource(thisShader, 1, csources, nil)
free()
gl.CompileShader(thisShader)

I got that code from the gl41core-cube example, which you can/should use as a reference:

https://github.com/go-gl/example/blob/ee0644b7c5650555db3c0f4d04f9ef5716e6c6ac/gl41core-cube/cube.go#L178-L183

Hopefully that fixes your problem.

I wonder if there's some change we can make to the documentation to make this solution more discoverable.

[splace]

thanks,

just wondering, why not put that inside the CreateShader function?

[dmitshur]

Sorry, I can't answer your question because I'm boarding a plane, see https://twitter.com/shurcool/status/871528913108971520. Hopefully someone else can answer it.

[errcw]

The short answer is that these bindings attempt to mirror the OpenGL function definitions as closely as possible. A higher level library could certainly wrap some of these sharp edges, but that's not the intention of this particular library.

[splace]

closing due to my misunderstanding.

[splace]

further to this, using Strs() func broke all my shaders....

go-gl/gl#77