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

rbtree infinite loop/crash #8618

Open
zmike opened this issue Sep 30, 2024 · 3 comments
Open

rbtree infinite loop/crash #8618

zmike opened this issue Sep 30, 2024 · 3 comments
Assignees
Labels
Bug Something isn't working

Comments

@zmike
Copy link
Contributor

zmike commented Sep 30, 2024

As I pasted to @spencer-lunarg, running this this piglit test with VVL causes an extended loop inside VVL on shutdown which eventually results in a crash:

ZINK_DEBUG=vvl MESA_LOADER_DRIVER_OVERRIDE=zink bin/object-namespace-pollution glBitmap framebuffer -auto -fbo

@spencer-lunarg spencer-lunarg added the Bug Something isn't working label Sep 30, 2024
@spencer-lunarg spencer-lunarg self-assigned this Sep 30, 2024
@spencer-lunarg
Copy link
Contributor

(notes)

If I turn off everything but Core Checks ( VK_LAYER_DISABLES=VK_VALIDATION_FEATURE_DISABLE_SHADERS_EXT,VK_VALIDATION_FEATURE_DISABLE_THREAD_SAFETY_EXT,VK_VALIDATION_FEATURE_DISABLE_OBJECT_LIFETIMES_EXT,VK_VALIDATION_FEATURE_DISABLE_UNIQUE_HANDLES_EXT,VK_VALIDATION_FEATURE_DISABLE_API_PARAMETERS_EXT) it will still crash

If I turn off core checks (VK_LAYER_DISABLES=VK_VALIDATION_FEATURE_DISABLE_CORE_CHECKS_EXT) it works as expected... so seems to be isolated to just core checks

I noticed from API dump it goes

vkBindBufferMemory()
vkBindBufferMemory()
PIGLIT: {"result": "pass" }
vkCreateImageView()
vkGetPhysicalDeviceImageFormatProperties2KHR()
vkCreateImage()
vkGetImageMemoryRequirements2()
vkAllocateMemory()
vkBindImageMemory()
vkCmdPipelineBarrier2() <---- memory corruption noticed here

@spencer-lunarg
Copy link
Contributor

seems all static const std::map are being corrupted, even in things in like GetAccessMask2CommonMap(), not sure yet when that corruption starts

@spencer-lunarg
Copy link
Contributor

so Piglet is calling exit(0)

#0 __run_exit_handlers stdlib/exit.c:108
#1 __GI_exit stdlib/exit.c:138
#2 piglit_report_result piglit/tests/util/piglit-util.c:245-

but it is then handling it piglit-framework-gl.c via the destory() but our std::map are being destroyed as a library under us during that exit(0) call

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants