PtrOffset causes "cgo argument has Go pointer to Go pointer" runtime error

[dmgard]

EDIT: using GODEBUG=cgocheck=0 can disable these checks but seems like kind of a hacky-workaround, especially if you need runtime pointer checks for other packages.

It seems that calling functions like gl.DrawElements using gl.PtrOffset to convert a gl buffer offset causes the Go runtime to intercept those offsets as if they were pointers into Go memory. This is just a toy example; I've run into this problem using large index/vertex buffers in other projects. Trying to index elements in the millions seems to semi-randomly throw errors.

Drilling down a bit:

// PtrOffset takes a pointer offset and returns a GL-compatible pointer.
// Useful for functions such as glVertexAttribPointer that take pointer
// parameters indicating an offset rather than an absolute memory address.
func PtrOffset(offset int) unsafe.Pointer {
	return unsafe.Pointer(uintptr(offset))
}

I'm already out of my depth here but I'm wondering why offsets have to be sent to OpenGL via CGO as unsafe.Pointer? Is there some obvious way around this error I'm missing?

Program to reproduce:

package main

import (
	"log"

	"github.com/go-gl/gl/v2.1/gl"
	"github.com/go-gl/glfw/v3.2/glfw"
)

// var pointers = make([]*int, 40*(1<<20))
var buffer = make([]byte, 48*(1<<20))

func main() {
	err := glfw.Init()

	if err != nil {
		log.Fatal(err)
	}

	window, err := glfw.CreateWindow(1024, 768, "Test", nil, nil)

	if err != nil {
		log.Fatal(err)
	}

	//for i := range pointers {
	//	pointers[i] = new(int)
	//}

	window.MakeContextCurrent()

	if err := gl.Init(); err != nil {
		log.Fatalln(err)
	}
	var vertBuf, indexBuf uint32

	gl.CreateBuffers(1, &vertBuf)
	gl.CreateBuffers(1, &indexBuf)

	gl.BindBuffer(gl.ARRAY_BUFFER, vertBuf)
	gl.BindBuffer(gl.ELEMENT_ARRAY_BUFFER, indexBuf)

	gl.BufferData(gl.ARRAY_BUFFER, len(buffer), gl.Ptr(buffer), gl.DYNAMIC_DRAW)
	gl.BufferData(gl.ELEMENT_ARRAY_BUFFER, len(buffer), gl.Ptr(buffer), gl.DYNAMIC_DRAW)

	// const NumDraws = 1000
	var NumDraws = len(buffer) / 4

	for i := 0; i < NumDraws; i++ {
		//offset := rand.Int() % 12000000 //+ 12000000
		offset := i

		//fmt.Printf("offset = %d", offset)

		gl.DrawElements(gl.TRIANGLES, 500000, gl.UNSIGNED_INT, gl.PtrOffset(offset))

		gl.DrawElementsInstancedARB(gl.TRIANGLES, 500000, gl.UNSIGNED_INT, gl.PtrOffset(offset), 1)
	}

	//for _, p := range pointers {
	//	*p++
	//}

	window.Destroy()
	glfw.Terminate()
}

[errcw]

As I understand it, the TL;DR is that Go does not allow non-pointer values in pointer types such as unsafe.Pointer. A small offset is very unlikely to be a valid pointer, hence the crash. The challenge is that the bindings are auto-generated based on the OpenGL XML specs, and these offsets are pointer parameters in the specs, hence are encoded as Go pointer types. Instead we should probably use uintptr as the Go type, which should in theory sidestep the issue, but that'd be a huge breaking change to the bindings. +@shurcooL to comment once he's back.

[dmitshur]

Breaking change is okay if it's neccessary/unavoidable, as the current code is unusable. But it's a matter of figuring out whether that's the best fix.

But this issue, isn't it the same/related to #71?

[errcw]

Yep, this issue is related to #71, but it's somewhat simpler in that we are not required to change the OpenGL typedefs to change the Go type bindings.

[jeff-emanuel]

I agree with shurcooL. The sooner a fix can be made, the better, even if it is breaking. I also haven't had any success with GODEBUG=cgocheck=0. Only by setting GOGC=off are crashes eliminated entirely.

[errcw]

Unfortunately our options here are limited by Go/cgo requirements. As I indicated before, Go does not allow non-pointer values in pointer types, so declaring a parameter that might take an offset as unsafe.Pointer is invalid. However we cannot simply change the parameter type to uintptr because that parameter might take a pointer, and it is unsafe to pass Go pointers to C using non-pointer types (the GC must be aware that the Go memory requires pinning). Indeed, per this thread on golang-nuts, there is no appropriate Go type.

So where does that leave us? To start, gl.PtrOffset must return uintptr; returning unsafe.Pointer is simply incorrect. As for the function parameter type, I see a couple options:

1. Generate two functions, one that takes unsafe.Pointer for pointer values, and another that takes uintptr for offsets.
2. Privilege the offset version over the pointer version and only generate the uintptr version.

Both options require identifying parameters that are declared as void* but take non-pointer offset values. I don't see any better way than a whitelist, unfortunately.

Right now I'm leaning towards option 2, but I'd like to hear additional input.

[jeff-emanuel]

Thanks for the update and for the work on this package.

I currently pass both pointers and offsets to DrawElements, but for the cases where I'm passing a pointer to indices, I could put the indices in a buffer and avoid passing pointers. A more complicated case is MultiDrawElements or MultiDrawElementsBaseVertex where the indices parameter type is "const GLvoid * const * indices", which can be a combination of true pointer and offsets. I'm passing the address of the first element of a list containing PtrOffsets. How would that work?

	n := len(startIndexOffsets)
	offsets := make([]unsafe.Pointer,n,n)
	for i:=0;i<n;i++ {
		offsets[i] = gl.PtrOffset(startIndexOffsets[i])
	}
	// Uses bound GL_ELEMENT_ARRAY_BUFFER buffer for indices.
	gl.MultiDrawElementsBaseVertex(
		primitive,
		&counts[0], gl.UNSIGNED_INT, &offsets[0], int32(len(counts)),
		&baseVertices[0])

[errcw]

Aha, MultiDrawElements is additionally problematic, at least in the case where the indices parameter might contain pointers to index data rather than offsets in a bound buffer. When passing Go memory to C, cgo requires that the Go memory contain no pointers to other Go memory (AIUI Go wants to avoid transitive pinning). The implication is that only C-allocated memory will work for this use case, which is a definite ease-of-use hiccup.

My takeaway is that simply assuming we can transform the API to use uintptr is infeasible, because folks are actively using these pointer-or-offset parameters to pass pointers, so we should instead generate additional WithOffset methods that swap unsafe.Pointer for uintptr. Additionally, we should clarify in the README how folks should handle pointer-to-pointer use cases.

[jeff-emanuel]

WithOffset methods would work for me. Thanks.

[pwaller]

Sounds like this thread has a potential resolution, adding WithOffset, it just needs someone willing to do the work to implement and test, correct?

[dmgard]

Works for me too.