Closed phr00t closed 4 years ago
From the available stack trace. This appears to be due to the following: GetPhysicalDeviceCalibrateableTimeDomainsEXT
Any info on what causes this?
Process: VixenTest [1953] Path: /Users/USER/*/VixenTest.app/Contents/MacOS/VixenTest Identifier: ??? Version: ??? (???) Code Type: X86-64 (Native) Parent Process: clion [504] Responsible: clion [504] User ID: 501
Date/Time: 2020-02-04 16:26:58.399 -0500 OS Version: Mac OS X 10.15.3 (19D76) Report Version: 12 Bridge OS Version: 3.0 (14Y908) Anonymous UUID: 43B4DD66-A37C-5CB8-5A58-0B2D8EC7FE23
Time Awake Since Boot: 440 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [1953]
VM Regions Near 0: --> __TEXT 0000000101eaa000-0000000101fda000 [ 1216K] r-x/r-x SM=COW /Users/USER/*/VixenTest.app/Contents/MacOS/VixenTest
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libVkLayer_khronos_validation.dylib 0x000000010848ab2c get_dispatch_key(void const) + 12
1 libVkLayer_khronos_validation.dylib 0x00000001084e2f43 vulkan_layer_chassis::GetPhysicalDeviceCalibrateableTimeDomainsEXT(VkPhysicalDevice_T, unsigned int, VkTimeDomainEXT) + 35
2 libvulkan.1.2.131.dylib 0x000000010238597a GetPhysicalDeviceCalibrateableTimeDomainsEXT + 74
3 0x0000000101f8d060 Vixen::Vulkan::Device::SelectDevice(Vixen::Vulkan::Application const&) + 160 (vulkan.hpp:67561)
4 0x0000000101f8cb98 Vixen::Vulkan::Device::Device(std::1::unique_ptr<Vixen::Vulkan::Application, std::__1::default_delete
Thread 1:: SDLTimer 0 libsystem_kernel.dylib 0x00007fff695b8ce6 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff6967a185 _pthread_cond_wait + 701 2 org.libsdl.SDL2 0x00000001023fc33e 0x1023d9000 + 144190 3 org.libsdl.SDL2 0x00000001023fd860 0x1023d9000 + 149600 4 org.libsdl.SDL2 0x00000001023fe545 0x1023d9000 + 152901 5 org.libsdl.SDL2 0x00000001023fe05c 0x1023d9000 + 151644 6 org.libsdl.SDL2 0x00000001023fdab9 0x1023d9000 + 150201 7 libsystem_pthread.dylib 0x00007fff69679e65 _pthread_start + 148 8 libsystem_pthread.dylib 0x00007fff6967583b thread_start + 15
Thread 2: 0 libsystem_pthread.dylib 0x00007fff69675818 start_wqthread + 0
Thread 3: 0 libsystem_pthread.dylib 0x00007fff69675818 start_wqthread + 0
Thread 4: 0 libsystem_pthread.dylib 0x00007fff69675818 start_wqthread + 0
Thread 5: 0 libsystem_pthread.dylib 0x00007fff69675818 start_wqthread + 0
Thread 6:: AMCP Logging Spool 0 libsystem_kernel.dylib 0x00007fff695b6296 semaphore_wait_trap + 10 1 com.apple.audio.caulk 0x00007fff65659a96 caulk::mach::semaphore::wait() + 16 2 com.apple.audio.caulk 0x00007fff65659922 caulk::semaphore::timed_wait(double) + 106 3 com.apple.audio.caulk 0x00007fff65659734 caulk::concurrent::details::worker_thread::run() + 30 4 com.apple.audio.caulk 0x00007fff65659174 void caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::)(), std::__1::tuple<caulk::concurrent::details::worker_thread> > >(void) + 45 5 libsystem_pthread.dylib 0x00007fff69679e65 _pthread_start + 148 6 libsystem_pthread.dylib 0x00007fff6967583b thread_start + 15
Thread 7: 0 libsystem_kernel.dylib 0x00007fff695b6296 semaphore_wait_trap + 10 1 com.apple.audio.caulk 0x00007fff65659a96 caulk::mach::semaphore::wait() + 16 2 com.apple.audio.caulk 0x00007fff65659922 caulk::semaphore::timed_wait(double) + 106 3 com.apple.audio.caulk 0x00007fff65659734 caulk::concurrent::details::worker_thread::run() + 30 4 com.apple.audio.caulk 0x00007fff65659174 void caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::)(), std::__1::tuple<caulk::concurrent::details::worker_thread> > >(void) + 45 5 libsystem_pthread.dylib 0x00007fff69679e65 _pthread_start + 148 6 libsystem_pthread.dylib 0x00007fff6967583b thread_start + 15
Thread 8: 0 libsystem_kernel.dylib 0x00007fff695b62ae semaphore_timedwait_trap + 10 1 libdispatch.dylib 0x00007fff6941ca1b _dispatch_sema4_timedwait + 76 2 libdispatch.dylib 0x00007fff6941ce42 _dispatch_semaphore_wait_slow + 58 3 libdispatch.dylib 0x00007fff6942a642 _dispatch_worker_thread + 318 4 libsystem_pthread.dylib 0x00007fff69679e65 _pthread_start + 148 5 libsystem_pthread.dylib 0x00007fff6967583b thread_start + 15
Thread 0 crashed with X86 Thread State (64-bit): rax: 0x00000001084e2f20 rbx: 0x0000000000000000 rcx: 0x00007fceafc4b078 rdx: 0x0000000000000000 rdi: 0x0000000000000000 rsi: 0x00007ffeedd52434 rbp: 0x00007ffeedd51960 rsp: 0x00007ffeedd51960 r8: 0x00007fceafee2e2c r9: 0x00000000eafee2f9 r10: 0x00000000fe000000 r11: 0x0000000000000000 r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 rip: 0x000000010848ab2c rfl: 0x0000000000010202 cr2: 0x0000000000000000
Logical CPU: 0 Error Code: 0x00000004 (no mapping for user data write) Trap Number: 14
Binary Images:
0x101eaa000 - 0x101fd9ff3 + (??? - ???)
External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 2107 thread_create: 0 thread_set_state: 57
VM Region Summary: ReadOnly portion of Libraries: Total=554.8M resident=0K(0%) swapped_out_or_unallocated=554.8M(100%) Writable regions: Total=117.8M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=117.8M(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced) =========== ======= ======= Activity Tracing 256K 1 CoreAnimation 4K 1 Dispatch continuations 16.0M 1 Foundation 4K 1 IOKit 15.5M 2 Kernel Alloc Once 8K 1 MALLOC 89.0M 54 MALLOC guard page 32K 8 STACK GUARD 56.0M 9 Stack 12.1M 9 VM_ALLOCATE 204K 9 DATA 24.7M 280 DATA_CONST 44K 4 FONT_DATA 4K 1 LINKEDIT 371.1M 10 OBJC_RO 32.0M 1 OBJC_RW 1776K 1 TEXT 183.8M 276 UNICODE 564K 1 mapped file 49.9M 12 shared memory 636K 15 =========== ======= ======= TOTAL 853.5M 697
Model: MacBookPro14,3, BootROM 204.0.0.0.0, 4 processors, Quad-Core Intel Core i7, 2.9 GHz, 16 GB, SMC 2.45f1 Graphics: kHW_IntelHDGraphics630Item, Intel HD Graphics 630, spdisplays_builtin Graphics: kHW_AMDRadeonPro560Item, Radeon Pro 560, spdisplays_pcie_device, 4 GB Memory Module: BANK 0/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x80AD, 0x483943434E4E4E434C47414C41522D4E5644 Memory Module: BANK 1/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x80AD, 0x483943434E4E4E434C47414C41522D4E5644 AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x173), Broadcom BCM43xx 1.0 (7.77.106.3 AirPortDriverBrcmNIC-1440.1) Bluetooth: Version 7.0.3f5, 3 services, 27 devices, 1 incoming serial ports Network Service: Wi-Fi, AirPort, en0 USB Device: USB 3.0 Bus USB Device: Apple T1 Controller Thunderbolt Bus: MacBook Pro, Apple Inc., 41.3 Thunderbolt Bus: MacBook Pro, Apple Inc., 41.3
Woah, thank you for looking into this! Did you build a test app with my Focus engine for this? I probably should have provided a test app myself 🤦♂
I'm not familar with GetPhysicalDeviceCalibrateableTimeDomainsEXT or what is going on here, so I'm hoping you are asking someone else! Let me know if I can be of further assistance.
That's a function from the Vulkan extension VK_EXT_calibrated_timestamps
. I haven't implemented that extension yet, but I plan to after I add support for Metal 3.0's new timestamp queries.
Is your engine's Vulkan layer calling this function without checking for that extension? Or maybe some other part is?
I am not calling this extension at all. It is crashing on this extension when trying to enumerate devices.
There is a call to instance.enumeratePhysicalDevices()
using Vulkan-Hpp and it crashes with the stack trace shown above using:
Vulkan SDK 1.2.131.1
Okay this is concerning. I've uninstalled, reinstalled, uninstalled, then reinstalled the SDK and its now working. I've changed zero lines of code. So something seems unstable....
@MattGuerrette @cdavis5e following up with this -- is there anything I can do to help here? Did you build a Xenko/Focus project to get to this error?
The only thing somewhat related to VK_EXT_calibrated_timestamps in my engine was a call to https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCmdWriteTimestamp.html
Does that require that extension? Could this be a potential cause of the problem?
@phr00t I actually ran across this issue with my own personal engine. What is concerning is the issue was 100% reproducible until I started installing/uninstalling various SDK versions. Finally, I went back and reinstalled 1.2.131.1 and it worked fine....
As far as calling something that would use VK_EXT_calibrated_timestamps. My engine currently is quite simple, and renders basically a single triangle. I've been using Vulkan-Hpp the Vulkan C++ api and it was crashing with this error simply enumerating the devices....
Here is what is particularly concerning if you look at the following:
0 libVkLayer_khronos_validation.dylib 0x000000010848ab2c get_dispatch_key(void const) + 12 1 libVkLayer_khronos_validation.dylib 0x00000001084e2f43 vulkan_layer_chassis::GetPhysicalDeviceCalibrateableTimeDomainsEXT(VkPhysicalDevice_T, unsigned int, VkTimeDomainEXT) + 35 2 libvulkan.1.2.131.dylib 0x000000010238597a GetPhysicalDeviceCalibrateableTimeDomainsEXT + 74 3 0x0000000101f8d060 Vixen::Vulkan::Device::SelectDevice(Vixen::Vulkan::Application const&) + 160 (vulkan.hpp:67561)
My engine calls into vulkan.hpp:67561 here in the stack trace. This is what that code does:
do
{
result = static_cast<Result>( d.vkEnumeratePhysicalDevices( m_instance, &physicalDeviceCount, nullptr ) );
if ( ( result == Result::eSuccess ) && physicalDeviceCount )
{
physicalDevices.resize( physicalDeviceCount );
result = static_cast<Result>( d.vkEnumeratePhysicalDevices( m_instance, &physicalDeviceCount, reinterpret_cast<VkPhysicalDevice*>( physicalDevices.data() ) ) );
}
} while ( result == Result::eIncomplete );
Just a basic loop checking for available physical devices right?
Well look at where it goes in the stack trace next....
2 libvulkan.1.2.131.dylib 0x000000010238597a GetPhysicalDeviceCalibrateableTimeDomainsEXT + 74
Why does it go here? No clue. I have a couple guesses:
1) Maybe the dispatch system in Vulkan-Hpp which holds the function pointers for the interface was crashing calling a function pointer it shouldn't have or couldn't have
2) The latest Vulkan SDK has some requirement on vkGetPhysicalDeviceCalibrateableTimeDomainsEXT for device enumeration
I can't prove for certain but in the latest Vulkan SDK 1.2.131.2 there is a release note mentioning the following:
In the 1.2.131.1 SDK, a bug exists when using vkGetInstanceProcAddr to get a function pointer to an extension API that was integrated into Vulkan 1.2. Doing so will give a function pointer that may crash when validation is enabled. This SDK resolves this issue.
This sounds like it could be related to the issue I was experiencing and along the lines of 1 above.
Does this problem appear when linking directly to MoltenVK? Or is this an issue with the SDK and layers? If the latter, make sure you file a bug with the SDK team.
make sure you file a bug with the SDK team.
Closing this. Please reopen if this bug appears when linking directly to MoltenVK.
@billhollings @MattGuerrette @cdavis5e I couldn't find a way to reopen this, so I made a new issue:
https://github.com/KhronosGroup/MoltenVK/issues/846
I also just added a direct download debug build of my game, which uses MoltenVK, to better troubleshoot.
I've been working on Xenko, specifically my fork Focus (http://github.com/phr00t/focusengine), which only supports Vulkan. I currently run built games on MacOSX using the MoltenVK SDK v1.101, which seems to work fine.
Using any SDK release version later than v1.101 (like v1.106+) first caused an error that a Vulkan feature/extension was unsupported and my application wouldn't run. I modified my Vulkan implementation to only request features listed as supported by the Vulkan device (and also added the METAL/OSX SURFACE feature/extension), hoping that would resolve the issue.
Now all I get is "segfault: 11".
My Vulkan implementation works fine on Windows on all tested configurations (Intel HD, NVIDIA & AMD GPUs of varying versions). My games startup and run fine on the MoltenVK SDK v1.101, just nothing more recent. Am I "safe" sticking with this SDK version? What changed between these two versions that might be affecting me here?
Any help is appreciated!