Skip to content
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

Test layer triggers crash if enabled #102

Closed
djdeath opened this issue Nov 13, 2018 · 4 comments
Closed

Test layer triggers crash if enabled #102

djdeath opened this issue Nov 13, 2018 · 4 comments
Assignees

Comments

@djdeath
Copy link
Member

djdeath commented Nov 13, 2018

I've tried this with a couple of application :

VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_test COGL_DRIVER=vulkan gdb --args ../cogl/examples/cogl-hello

Thread 1 "cogl-hello" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in  ()
#1  0x00007ffff3fd3753 in vkGetDeviceQueue (device=0x555555861fc0, queueNodeIndex=0, queueIndex=0, pQueue=0x55555579f780) at Vulkan-Loader/loader/trampoline.c:1003
#2  0x00007ffff5fa37e1 in _cogl_vulkan_context_init (context=0x55555557f610, error=0x7fffffffd538) at driver/vulkan/cogl-driver-vulkan.c:302
#3  0x00007ffff6021918 in _cogl_winsys_context_init (context=0x55555557f610, error=0x7fffffffd538) at winsys/cogl-winsys-vulkan-x11.c:278
#4  0x00007ffff5fb5235 in cogl_context_new (display=0x555555591d00, error=0x7fffffffd538) at cogl-context.c:237
#5  0x000055555555543a in main (argc=1, argv=0x7fffffffd678) at cogl-hello.c:89

Same with gfxbench :

VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_test gdb --args ./bin/testfw_app -t vulkan_5_normal --gfx=xcb_vulkan -w1280 -h720

Thread 2 "testfw_app" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff519c700 (LWP 10139)]
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff69c4753 in vkGetDeviceQueue (device=0x7ffff0390350, queueNodeIndex=0, queueIndex=0, pQueue=0x7ffff0006c18) at Vulkan-Loader/loader/trampoline.c:1003
#2  0x00000000007fc6ec in ?? ()
#3  0x00000000007fe024 in ?? ()
#4  0x00000000007eb3e6 in ?? ()
#5  0x0000000000768170 in ?? ()
#6  0x0000000000768a45 in ?? ()
#7  0x00000000004282b2 in ?? ()
#8  0x000000000061354f in ?? ()
#9  0x0000000000610856 in ?? ()
#10 0x00007ffff70bbf2a in start_thread (arg=0x7ffff519c700) at pthread_create.c:463
#11 0x00007ffff6596edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
@lenny-lunarg lenny-lunarg self-assigned this Nov 13, 2018
@lenny-lunarg
Copy link
Contributor

I'm not sure this is really a problem. We never intended to distribute the test layer. It's only real purpose is to create a layer that we can enable/disable as part of the loader tests. As a result, we never bother getting far enough to create a device with that layer.

Is there any reason you want to be enabling the layer? I don't think it does anything useful.

@djdeath
Copy link
Member Author

djdeath commented Nov 13, 2018

I’m trying to figure out my rendercmd crash and so far all the layers I’ve tried are crashing:

  • Test layer
  • wrap object layer
  • renderdoc layer

@lenny-lunarg
Copy link
Contributor

Your stack trace looks like you're not actually entering the enabled layer. It looks to me like the loader's dispatch table has a null pointer for the function in question. This could mean that there's a loader bug or the layers are returning their function pointers wrong.

My advice would be to see if validation layers work. Those should be doing all of the initialization behavior correct, so if even those crash we either have a bug or something wrong with your system's configuration.

@lenny-lunarg
Copy link
Contributor

We haven't progressed this in quite a while and it still sounds to me like there's no error here because the layer was never meant to be used outside of the tests. As such, I'm closing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants