-
Notifications
You must be signed in to change notification settings - Fork 54
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.
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
Go pointer stored into non-Go memory crashes #42
Comments
Are you using the Go race detector? It caused similar errors for me when I knew for sure that there was nothing wrong. |
I'm pretty sure this is the issue:
var cpApplicationName_allocs *cgoAllocMap
refb0af7378.pApplicationName, cpApplicationName_allocs = unpackPCharString(x.PApplicationName)
allocsb0af7378.Borrow(cpApplicationName_allocs)
// unpackPCharString represents the data from Go string as *C.char and avoids copying.
func unpackPCharString(str string) (*C.char, *cgoAllocMap) {
h := (*stringHeader)(unsafe.Pointer(&str))
return (*C.char)(h.Data), cgoAllocsUnknown
} When c-for-go project started in 2015, it was relatively safe practice to pass memory behind I'll need to fix vulkan-go bindings to so |
Perhaps a rewrite for the bindings would be in order? The bindings have worked fine for me but there are small issues like this and also some performance and memory safety questions I'm worried about, particularly with regards to wrapped structs. |
@jclc as been discussed in xlab/c-for-go#86 performance and memory safety questions with wrapped structs is a phantom problem — I've never seen any reasonable numbers, and for my use cases there is no issues at all.. There are some tricky parts in binding generation, like callbacks, especially with custom memory allocators for Vulkan. I think this is a standalone feature that needs to be improved. But there is no point in debates about performance vs safety. If you need both, then one should use Rust. Regarding this particular case with zero-alloc string — initially this has beed implemented as a way to avoid allocation pressure. Which turns out to be not so safe and not so useful in 2020. So I'll add additional mem copy for (unnoticeable) sacrifice of performance. |
Thank you! No, I haven't used the race detector.
That would be amazing, I noticed the Btw, thank you very much for doing this project, despite GC, runtime, and all of that, I've had great experiences with Go and OpenGL in the past, it's really nice to be able to use vulkan now. |
I tried the naive approach of simply replacing |
Hi, I tried to enable the debug reporting callback on the go vulkan demo (vulkancube) by setting VulkanDebug() to return true:
It crashes with:
I'm pretty worried about this issue because, when I restored the original code to disable the reporting functionality, but enabled Go's CGO checker to the maximum with
GODEBUG=cgocheck=2
,vk.CreateInstance
crashed hard due to the same problem:Is this a false positive in the go tooling? Is this a real issue with these bindings? If so, I'd gladly try to help
The text was updated successfully, but these errors were encountered: