Sometimes hit unreachable code in Vulkan backend on starting my application

[bonsairobo]

Short info header:

• GFX version: gfx-backend-vulkan-0.3.3
• OS: Window 10 Version 2004
• GPU: Nvidia GTX 980

thread '<unnamed>' panicked at 'internal error: entered unreachable code', .cargo\registry\src\github.com-1ecc6299db9ec823\gfx-backend-vulkan-0.3.3\src\device.rs:1352:18

This happens to be in Device::bind_image_memory.

[kvark]

Would you want to update to latest? 0.3.3 is a very old version.

[bonsairobo]

I guess I need to wait for Amethyst to update. Just wanted to see if this was a known issue. I didn't find it when I searched.

On Sat, Aug 15, 2020, 8:10 PM Dzmitry Malyshau [email protected] wrote:

Would you want to update to latest? 0.3.3 is a very old version.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gfx-rs/gfx/issues/3339#issuecomment-674471828, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYUSHM6NKZRROMCPNUTERLSA5E2TANCNFSM4QAS447Q .

[kvark]

Perhaps, you could provide the full call stack? Also, debug level logging would be useful.

[bonsairobo]

I can turn that on. I'll have to get a repro, which is somewhat rare.

On Sat, Aug 15, 2020, 8:18 PM Dzmitry Malyshau [email protected] wrote:

Perhaps, you could provide the full call stack? Also, debug level logging would be useful.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gfx-rs/gfx/issues/3339#issuecomment-674472286, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYUSHPBL3CJTUA4HZNSPATSA5FX7ANCNFSM4QAS447Q .

[bonsairobo]

OK I have a consistent repro, seemingly out of nowhere. I ran it in debug mode to get some logging:

[WARN][gfx_backend_vulkan] 
VALIDATION [UNASSIGNED-CoreValidation-MemTrack-InvalidAliasing (0)] : Non-linear image 0x293 is aliased with linear buffer 0x28d which may indicate a bug. For further info refer to the Buffer-Image Granularity section of the Vulkan specification. (https://www.khronos.org/registry/vulkan/specs/1.0-extensions/xhtml/vkspec.html#resources-bufferimagegranularity)
object info: (type: IMAGE, hndl: 659)

[WARN][gfx_backend_vulkan] 
VALIDATION [UNASSIGNED-CoreValidation-MemTrack-InvalidAliasing (0)] : Non-linear image 0x293 is aliased with linear buffer 0x28d which may indicate a bug. For further info refer to the Buffer-Image Granularity section of the Vulkan specification. (https://www.khronos.org/registry/vulkan/specs/1.0-extensions/xhtml/vkspec.html#resources-bufferimagegranularity)
object info: (type: IMAGE, hndl: 659)

[ERROR][gfx_backend_vulkan] 
VALIDATION [VUID-vkBindImageMemory-memoryOffset-01048 (0)] : vkBindImageMemory(): memoryOffset is 0x709700 but must be an integer multiple of the VkMemoryRequirements::alignment value 0x400, returned from a call to vkGetImageMemoryRequirements with image. The Vulkan spec states: memoryOffset must be an integer multiple of the alignment member of the VkMemoryRequirements structure returned from a call to vkGetImageMemoryRequirements with image (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkBindImageMemory-memoryOffset-01048)
object info: (type: IMAGE, hndl: 659)

[ERROR][gfx_backend_vulkan] 
VALIDATION [VUID-vkBindImageMemory-memoryOffset-01048 (0)] : vkBindImageMemory(): memoryOffset is 0x709700 but must be an integer multiple of the VkMemoryRequirements::alignment value 0x400, returned from a call to vkGetImageMemoryRequirements with image. The Vulkan spec states: memoryOffset must be an integer multiple of the alignment member of the VkMemoryRequirements structure returned from a call to vkGetImageMemoryRequirements with image (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkBindImageMemory-memoryOffset-01048)
object info: (type: IMAGE, hndl: 659)

[ERROR][gfx_backend_vulkan] 
VALIDATION [NVIDIA (1)] : vkBindImageMemory: memoryOffset 709700 is not aligned to 400
object info: (type: IMAGE, hndl: 1849865995856)

thread '<unnamed>' panicked at 'internal error: entered unreachable code', C:\Users\Duncan\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx-backend-vulkan-0.3.3\src\device.rs:1352:18

Unfortunately, I ran it with RUST_BACKTRACE=1 but I did not get a backtrace ¯\(ツ)/¯

[kvark]

So your code contains a few errors that are hinted by the validation messages. gfx-rs is totally unsafe and is not in the business to fix this for you. Crashing is a totally reasonable thing to do if you aren't following the valid usage rules (of Vulkan). Please try to fix your code so that vulkan validation layers are happy, and see if it still crashes.

[bonsairobo]

Would it be unreasonable for gfx-rs to panic with a different error message or something other than unreachable!()? I think unreachable!() is intended for conditions that the library actually doesn't think are even possible, not just error conditions.

[kvark]

In this case, it's unreachable in a valid-written application. I'd be happy to have this fixed to a panic! (want to make a PR?), but this isn't going to help your application.

[charles-r-earp]

In this case, it's unreachable in a valid-written application. I'd be happy to have this fixed to a panic! (want to make a PR?), but this isn't going to help your application.

I've run into a similar if not identical issue. Firstly, unreachable should mark code that is actually unreachable, even with bad inputs. There's actually quite a few places where this is used improperly. Better is unimplemented or just panic. Secondly, it would be nice to actually print the error code in the panic, so that users can troubleshoot, given that your contention is that it is a user space error, then the error code, or maybe a helpful message, should be provided so that the user can determine what the issue is. Otherwise, they would just assume that it is a bug.

[kvark]

Firstly, unreachable should mark code that is actually unreachable, even with bad inputs.

Ideally, yes. In our case though, this is unsafe API, so if run-time constraints are not fulfilled, anything can happen, including unreachable.

Better is unimplemented or just panic.

Panic is certainly better, and I'm happy to have a proper panic with a nice error message, but unimplemented is probably not.

should be provided so that the user can determine what the issue is

There is a million ways to misuse a low-level unsafe API. We can only help you so much with trying to catch this mis-use. We know we aren't going to cover even 20% of the bad cases with those checks. So adding them is a best-effort thing, and help is appreciated.

Otherwise, they would just assume that it is a bug.

Again, if users are calling unsafe functions without proper deliberation, they are free to assume anything.