Fix egl_fence_persistent_buffer deinit on GLES 2.0#435
Closed
enunes wants to merge 1 commit intoKhronosGroup:mainfrom
Closed
Fix egl_fence_persistent_buffer deinit on GLES 2.0#435enunes wants to merge 1 commit intoKhronosGroup:mainfrom
enunes wants to merge 1 commit intoKhronosGroup:mainfrom
Conversation
Contributor
|
This is now being tested and reviewed in Khronos CI. |
Contributor
|
How's the testing going? |
On GLES 2.0 only drivers, the egl_fence_persistent_buffer test fails to create its GLES 3.1 context and an exception is thrown at chooseSingleConfig, which aborts its init early. The initialization doesn't reach initGLFunctions and GL function pointers are left uninitialized, which causes a segfault and crash in the deinit path. Fix the deinit path so that it doesn't crash but just reports "No matching EGL config found" like other EGL tests with those drivers. Affects: dEQP-EGL.functional.fence_sync.valid.egl_fence_persistent_buffer Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
abaf585 to
ba1d485
Compare
Contributor
Author
|
This has been here for so long that I don't know if it was avoided in some other way. I rebased and (re)accepted the CLA though after a github ping, the fix still seems to still apply. |
Contributor
|
Re-bumping this one in the internal system |
Contributor
|
Khronos members CL: https://gerrit.khronos.org/c/vk-gl-cts/+/17893 |
lordalcol
pushed a commit
that referenced
this pull request
Aug 29, 2025
On GLES 2.0 only drivers, the egl_fence_persistent_buffer test fails to create its GLES 3.1 context and an exception is thrown at chooseSingleConfig, which aborts its init early. The initialization doesn't reach initGLFunctions and GL function pointers are left uninitialized, which causes a segfault and crash in the deinit path. Fix the deinit path so that it doesn't crash but just reports "No matching EGL config found" like other EGL tests with those drivers. Affects: dEQP-EGL.functional.fence_sync.valid.egl_fence_persistent_buffer Public PR: #435 Change-Id: Idd9fc6f565f37a1e37a5960f739adf05a0ca875f Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Contributor
|
This is currently done in the main branch. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On GLES 2.0 only drivers, the egl_fence_persistent_buffer test fails to create its GLES 3.1 context and an exception is thrown at chooseSingleConfig, which aborts its init early.
The initialization doesn't reach initGLFunctions and GL function pointers are left uninitialized, which causes a segfault and crash in the deinit path.
Fix the deinit path so that it doesn't crash but just reports "No matching EGL config found" like other EGL tests with those drivers.
Affects:
dEQP-EGL.functional.fence_sync.valid.egl_fence_persistent_buffer
This has been crashing on two GLES 2.0 drivers on mesa since this CTS update https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24947 .