ngscopeclient / scopehal-apps

ngscopeclient and other client applications for libscopehal.
https://www.ngscopeclient.org/
BSD 3-Clause "New" or "Revised" License
534 stars 83 forks source link

macOS: "Failed to load vulkan library" crash on launch #688

Open rgov opened 4 months ago

rgov commented 4 months ago

I built ngscopeclient for macOS but it crashes immediately:

$ DYLD_PRINT_INITIALIZERS=1 VK_LOADER_DEBUG=all ngscopeclient
INFO:              Vulkan Loader Version 1.3.277
dyld[78397]: running initializer 0x1018b665c in /opt/homebrew/Cellar/ngscopeclient/HEAD-6d43215/lib/libscopehal.dylib
dyld[78397]: running initializer 0x1018c8adc in /opt/homebrew/Cellar/ngscopeclient/HEAD-6d43215/lib/libscopehal.dylib
libc++abi: terminating due to uncaught exception of type std::runtime_error: Failed to load vulkan library!

Backtrace:

    frame #9: 0x00000001018b68bc libscopehal.dylib`vk::DynamicLoader::DynamicLoader(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) + 112
    frame #10: 0x00000001018b672c libscopehal.dylib`vk::raii::Context::Context() + 40
    frame #11: 0x00000001018c8af8 libscopehal.dylib`_GLOBAL__sub_I_VulkanInit.cpp + 28
    frame #12: 0x000000018c96da24 dyld`invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const + 168

The crash happens when dyld runs initializers, before logging is set up. It is related to the initialization of the global Vulkan context object, which triggers some dynamic loading behavior in Vulkan.

https://github.com/ngscopeclient/scopehal/blob/af34b246b2a14608dcc1c5d51b0109ca97f5466e/scopehal/VulkanInit.cpp#L54-L57

https://github.com/KhronosGroup/Vulkan-Headers/blob/5a5c9a643484d888873e32c5d7d484fae8e71d3d/include/vulkan/vulkan_raii.hpp#L2713-L2725

This is a new crash for me in the past few months. Maybe due to a difference between using the Vulkan SDK and installing vulkan-headers from Homebrew?

rgov commented 4 months ago

Basically a dupe of #622, it just looks different.

d235j commented 4 months ago

I'm not sure why dynamic load of libvulkan.dylib is attempted when the library is already loaded (e.g. by dyld, from being in the library link paths for the executable, which can be viewed by otool -L on macOS). Reopening this as a separate bug from #622.

d235j commented 4 months ago

This looks like an incorrect assumption in the Vulkan headers. Opened https://github.com/KhronosGroup/Vulkan-Hpp/issues/1811.