I just want to leave my solution here, since I am sure I am not the last person to run into this.
The issue (as others have suggested and initially assumed) is indeed that go expects a pointer where there is none. This only leads to errors when the GC scans the stack if I interpret my results correctly. Fortunately recent versions of vulkan.h allow you to override the define like this: // #define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef uint64_t object; // #include <vulkan/vulkan.h> import "C" If you are compiling exclusively for 32bit pointer architectures this is not necessary, but won't do any harm either (do it for the sake of portability). I brought this up on the vulkan side of things and found out that this seems to be the only way to achieve a strong typedef in some C descendants. That big benefit imo justifies the small inconvenience of having to override this in some garbage collected languages, so I decided to close the issue. On Sunday, December 18, 2016 at 8:13:39 PM UTC+1, Florian Uekermann wrote: > > Well, I am pretty sure I was wrong about something. Turning of the garbage > collector results in no error. Any smart ideas for debugging this? > > On Sunday, December 18, 2016 at 4:20:25 PM UTC+1, Florian Uekermann 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? >> > -- 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.
