I may be misdiagnosing the problem, but I think go is doing a problematic check of the value of C pointer types pointers.
The following runtime error is reproducible, but does not always happen in a program: runtime: writebarrierptr *0xc420326a90 = 0x12 fatal error: bad pointer in write barrier The stack trace indicates that the offending line is the last one in the following snippet: var bi C.VkRenderPassBeginInfo bi.sType = C.VK_STRUCTURE_TYPE_RENDER_PASS_BEGIN_INFO bi.renderPass = renderpass I checked the address of the .renderPass field and it is indeed 0xc420326a90 and the value of renderpass is 18. As you may have recognized by now, I am using the vulkan C bindings. The .renderPass field has type C.VkRenderPass. A quick look at vulkan.h yields the following: #if defined(__LP64__) || defined(_WIN64) || defined(__x86_64__) || defined(_M_X64) || defined(__ia64) || defined (_M_IA64) || defined(__aarch64__) || defined(__powerpc64__) #define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef struct object##_T *object; #else #define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef uint64_t object; #endif ... VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkRenderPass) So it seems to me that Vulkan uses a pointer type on 64bit archs to store a (potentially non-pointer) handle. Given that structs with these handles are very common, the workaround of allocating the bi variable on the C heap is a lot of unnecessary work and a bit of a performance issue. I am not quite sure what a writebarrier is in this context, so I am not sure if deactivating this check creates more issue (GC)? Can someone give some insight into what the long-term options are for go with respect to this? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.