API dump layer breaks hello_xr on Linux about openxr-sdk-source HOT 11 CLOSED

I'll try to get a linux system set up, Buster installed, and Monado built. In the meantime, can you help me possibly debug this a little? In the app, does it give any indication of failure? Like xrGetVulkanGraphicsRequirementsKHR returns an error? It looks like the app decides to terminate and call xrDestroyInstance after calling GetVulkanGraphicsRequirements, so I'm hoping the apidump layer just didn't return status correctly or maybe doesn't understand Vulkan properly or something.

from openxr-sdk-source.

Looks like stdout and stderr got a little interleaved: I think this part is meaningful from the app:

[10:58:16.455][Error  ] XrResult failure [XR_ERROR_VALIDATION_FAILURE]
    Origin: pfnGetVulkanInstanceExtensionsKHR(instance, systemId, 0, &extensionNamesSize, nullptr)
    Source: ./src/tests/hello_xr/graphicsplugin_vulkan.cpp:1263

It may do this on Windows (oculus desktop) too, I just haven't tried.

Hopefully it's just a misunderstanding by the api dump layer - I know MS has found some issues with that layer and other platform-related things.

from openxr-sdk-source.

Great, thank you! Yeah, it sounds like it's not Linux specific. Maybe I can make apidump fail on Windows just by calling xrGetVulkanGraphicsRequirementsKHR

from openxr-sdk-source.

ApiDumpLayerRecordContent() never gets called (no output) so probably an exception is thrown.
buffer is nullptr for this call (first of two-call idiom, I think?):

        contents.emplace_back("char*", "buffer", buffer);

That's a std::tuple of three std::string, and string(nullptr) is undefined behavior, so probably the std library just threw an exception. I suppose a possible change is to have "buffer" generated as (buffer ? buffer : "(nullptr)") or some such. I'll look into the generator.

from openxr-sdk-source.

Oh interesting. The old "std::string(nullptr)" rears its head again, perhaps, go figure

from openxr-sdk-source.

An issue (number 1323) has been filed to correspond to this issue in the internal Khronos GitLab.

If you have a Khronos account, you can access that issue at KHR:openxr/openxr#1323.

from openxr-sdk-source.

@rpavlik - do you still have an environment that can test this?
KHR:openxr/openxr!1712

from openxr-sdk-source.

There's no particular environment needed - this now shows up in the packages even.

• ubuntu 19.10 ppa here: https://gitlab.freedesktop.org/monado/monado/-/wikis/distros/Ubuntu
• debian buster here: https://gitlab.freedesktop.org/monado/monado/-/wikis/distros/Debian
• you want at least to do sudo apt install libopenxr1-monado libopenxr-utils openxr-layer-apidump openxr-layer-corevalidation to get Monado, hello_xr, and the two layers
• no VR hardware required

I have not tested it on Windows yet.

# This works
env XR_ENABLE_API_LAYERS=XR_APILAYER_LUNARG_core_validation hello_xr -g Vulkan

# This exits immediately
env XR_ENABLE_API_LAYERS=XR_APILAYER_LUNARG_api_dump hello_xr -g Vulkan

from openxr-sdk-source.

I've just run it on Windows and verified that the nullptr passed in to xrGetVulkanInstanceExtensionsKHR is printed as "(nullptr)".

from openxr-sdk-source.

Merged in GitLab, will be in next release.

from openxr-sdk-source.

Fix released in 1.0.9

from openxr-sdk-source.