panic: runtime error: cgo argument has Go pointer to Go pointer
I am trying to follow https://vulkan-tutorial.com/ except using Go. I have done the tutorial once in C/C++, so I have a basic understanding of Vulkan (emphasis on basic). I also have some Go experience, but not much when it comes to CGo. I get the error in the title when running this code:
appInfo := vk.ApplicationInfo{}
appInfo.SType = vk.StructureTypeApplicationInfo
appInfo.PApplicationName = "Hello Triangle"
appInfo.ApplicationVersion = vk.MakeVersion(1, 0, 0)
appInfo.PEngineName = "No Engine"
appInfo.EngineVersion = vk.MakeVersion(1, 0, 0)
appInfo.ApiVersion = vk.ApiVersion10
createInfo := vk.InstanceCreateInfo{}
createInfo.SType = vk.StructureTypeInstanceCreateInfo
createInfo.PApplicationInfo = &appInfo
glfwExtensions := h.window.GetRequiredInstanceExtensions()
createInfo.EnabledExtensionCount = uint32(len(glfwExtensions))
createInfo.PpEnabledExtensionNames = glfwExtensions
createInfo.EnabledLayerCount = 0
result := vk.CreateInstance(&createInfo, nil, &h.instance)
if result != vk.Success {
return errors.New("failed to create instance!")
}
return nil
In particular, vk.CreateInstance is failing. I am not familiar enough with CGo and how memory sharing between the languages works to really know how to debug this issue. Any guidance?
Just had the same problem: It looks like this happens if &h.instance is allocated in a Go heap span. If you just declare a local (stack) variable like var instance vk.Instance and take the pointer from that, it seems to "work".
My understanding is, that any heap allocation may be deallocated at any time, due to the concurrent GC nature and the runtime cannot prove that the c function has access to it. However, the stack is at least guaranteed to live until the called function returns, so it is guaranteed that the memory location is valid until the c function returns. Actually, the c function may still leak that memory and fail later...
var v vk.Instance
must(vk.Error(vk.CreateInstance(instInfo, nil, &v)))
a.instance = v
Yeah, that's why Asche uses that pattern everywhere.
https://github.com/vulkan-go/asche/blob/d4b318b67e07d52979747970be6463817ea6ed18/platform.go#L74
Can't remember a scientific explanation for that now..