On Sun, Dec 18, 2016 at 7:20 AM, 'Florian Uekermann' via golang-nuts <golang-nuts@googlegroups.com> wrote: > 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?
If you have a C value that may or may not contain a pointer, then 1) you must use a non-pointer type for that value in Go; the typical choice is uintptr; 2) when the value is a pointer, it must be a pointer to memory allocated using the C memory allocator, not memory allocated using the Go memory allocator. The Go garbage collector does not support values that may or may not be pointers. A value with pointer type must contain a pointer. A value with non-pointer type must not contain a pointer. Ian -- 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.
