glfw: Vulkan loading base handle panics in release about mach HOT 10 CLOSED

Good point, I hadn't thought about that, and it just happened to work so my brain decided that "welp, our work here is done".

from mach.

pub fn getInstanceProcAddress(vk_instance: ?*opaque {}, proc_name: [*:0]const u8) callconv(.C) ?VKProc {

const vk_proc = @ptrCast(fn(instance: vk.Instance, procname: [*:0]const u8) vk.PfnVoidFunction, glfw.getInstanceProcAddress);

There is a calling convention mismatch here, getInstanceProcAddress is defined as having the C calling convention, while it's cast to a function pointer with unspecified calling convention. Note that the load function for Wrappers does not require any specific calling convention, specifically to allow you to load using functions that do not necessarily follow the Vulkan calling convention. This means that

- pub fn getInstanceProcAddress(vk_instance: ?*opaque {}, proc_name: [*:0]const u8) callconv(.C) ?VKProc {
+ pub fn getInstanceProcAddress(vk_instance: ?*opaque {}, proc_name: [*:0]const u8) ?VKProc {

and

const vk_proc = @ptrCast(fn(instance: vk.Instance, procname: [*:0]const u8) vk.PfnVoidFunction, glfw.getInstanceProcAddress);
self.vkb = try BaseDispatch.load(vk_proc);

should also resolve the problem.

from mach.

It's definitely a weird issue; your fix does stop the panic from happening, but removing the 'getError' call and catch also stops it. As well, when I run it with gdb, without the fix, it seems to panic before even calling root.main, instead panicking in 'start.zig', while measuring the c_envp parameter of start.main. On Windows 10 at least.

from mach.

Indeed, then we know the issue is cross platform as i tested on ubuntu 20.04.

I'm am having issues other places in my code on release, so I am starting to suspect there might be some weird miss compilations in zig master.

from mach.

After flipping a bunch of knobs on and off, I've discovered what I believe to be the culprit: in 'graphics_context.zig', inside the function GraphicsContext.init, the line of code:

const vk_proc = @ptrCast(fn(instance: vk.Instance, procname: [*:0]const u8) vk.PfnVoidFunction, glfw.getInstanceProcAddress);

It would seem that the issue here is to do with calling convention. By changing the line of code to:

const vk_proc = @ptrCast(fn(instance: vk.Instance, procname: [*:0]const u8) callconv(vk.vulkan_call_conv) vk.PfnVoidFunction, glfw.getInstanceProcAddress);

The panic no longer occurs, so it is very probable that the issue here is how the compiler is deciding to call the function that is calling all the weirdness.

Edit: in fact, this is probably even better:

const vk_proc = @ptrCast(vk.PfnGetInstanceProcAddr, glfw.getInstanceProcAddress);

from mach.

Tested and works. Good job! I'll close this issue, but keep the issue on the vulkan project.

from mach.

Thanks for reporting this and debugging! You are definitely right about the pointer cast missing a calling convention being the culprit here.

However, I want to call out that using vk.vulkan_call_conv is not right in this case. You should use callconv(.C) I believe as this is a GLFW C proc, not a Vulkan proc, as I described previously in #49 (comment)

Unfortunately, vulkan-zig does not declare vk.PfnGetInstanceProcAddr with the correct calling convention either, I have filed an issue: Snektron/vulkan-zig#30

The most correct change I see, aside from fixing that issue in zig-vulkan, is the following:

-const vk_proc = @ptrCast(fn(instance: vk.Instance, procname: [*:0]const u8) vk.PfnVoidFunction, glfw.getInstanceProcAddress);
+const vk_proc = @ptrCast(fn(instance: vk.Instance, procname: [*:0]const u8) callconv(.C) vk.PfnVoidFunction, glfw.getInstanceProcAddress);

from mach.

Since the mach wrapper does not really add any direct improvements, I vote for it to simply forward export of the function instead of having its own wrapper implementation. The only issue is that getError() will pollute other functions. A wrapper implementation could be introduced if this shows to be a problem

from mach.

Which error(s) does it panic with? Is it 'ApiUnavailable'?

from mach.

Which error(s) does it panic with? Is it 'ApiUnavailable'?

Included in the original issue: thread 1030138 panic: reached unreachable code

from mach.