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 [email protected].
For more options, visit https://groups.google.com/d/optout.
