-
-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
glfw: Vulkan loading base handle panics in release #99
Comments
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 |
The previous code cause a panic in release builds. This commit resolved that issue at the cost of leaking glfw errors. Resolves issue hexops#99
Which error(s) does it panic with? Is it 'ApiUnavailable'? |
Included in the original issue: |
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 |
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. |
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 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); |
Tested and works. Good job! I'll close this issue, but keep the issue on the vulkan project. |
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 Unfortunately, vulkan-zig does not declare 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); |
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". |
There is a calling convention mismatch here, - 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. |
Inital issue was filed in the vulkan example as I though it was a bug in that code and can be found here
The following will panic in release (but not in debug):
replacing the following code in mach-glfw resolves the issue:
vulkan.zig
with
The text was updated successfully, but these errors were encountered: