feat(texture): Tear down external textures on the render thread#182
Merged
Conversation
UnregisterTexture() previously destroyed the ExternalTexture (running glDeleteTextures) synchronously on the calling platform thread. That could race with an in-flight PopulateGLTexture() on the render thread and free the backing TBM buffer while the GPU still referenced it, causing heap corruption and "tbm_bo_free ... lock_cnt" crashes on the SW backend. - Add a completion-callback parameter to UnregisterTexture, plumbed through FlutterDesktopTextureRegistrarUnregisterExternalTexture, so callers learn when teardown has actually completed. - Add FlutterTizenEngine::PostRenderThreadTask(), a thin wrapper over the embedder API's PostRenderThreadTask. - UnregisterTexture now removes the texture from the map (blocking new lookups), then posts its destruction to the render thread. The engine runs that task only after any in-flight frame callback has completed, so it no longer races; glDeleteTextures runs on the thread that owns the GL context, and the completion callback fires only once teardown is done.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the texture unregistration process to defer the destruction of external textures and their GPU resources to the render thread using PostRenderThreadTask. Feedback indicates that if the engine is not running and the task is executed inline, calling OnMakeCurrent and UnregisterExternalTexture is unsafe due to a potentially destroyed GL context or null engine handle. A guard using engine->IsRunning() is suggested to prevent crashes.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
The render-thread teardown task posted by UnregisterTexture() captures a raw renderer pointer. If the engine shuts down before the task runs, PostRenderThreadTask() runs it inline and the renderer may already be destroyed, so gl_renderer->OnMakeCurrent() could touch a dangling GL context/renderer. Guard the OnMakeCurrent() call with engine->IsRunning(). UnregisterExternalTexture() stays unconditional: it is null-safe at the embedder boundary (a torn-down engine handle just yields an error return) and is the registrar's core teardown step, so guarding it would skip the mandatory unregistration in the non-running case (and breaks the RegisterUnregisterTexture unit test, whose engine is never run). Also reflow the FlutterDesktopTextureRegistrarUnregisterExternalTexture call to satisfy clang-format.
seungsoo47
force-pushed
the
webview_lwe_fix
branch
from
July 7, 2026 10:39
dcdc1a5 to
b390e73
Compare
xiaowei-guan
reviewed
Jul 8, 2026
xiaowei-guan
previously approved these changes
Jul 8, 2026
xiaowei-guan
self-requested a review
July 8, 2026 05:23
PostRenderThreadTask() ignored the embedder API's return value. If posting failed (e.g. engine shutdown began concurrently with the IsRunning() check), the heap-allocated task was never scheduled and never freed, and worse, the texture teardown/completion callback it carried would never run. Run the task inline when posting fails, mirroring the existing !engine_ fallback, instead of widening the API to return a bool that the sole caller couldn't act on any differently.
xiaowei-guan
approved these changes
Jul 8, 2026
seungsoo47
added a commit
to seungsoo47/plugins
that referenced
this pull request
Jul 15, 2026
…rash Rework WebView::Dispose() to tear resources down safely: - Detach all engine callbacks (including the missing "policy,response,decide") and defer evas_object_del() until the embedder's UnregisterTexture completion callback, so the engine-owned TBM surfaces are not freed while a raster-thread frame is still reading them (flutter-tizen/embedder#182). - Add is_alive_/is_disposing_ guards so async callbacks arriving after disposal no longer touch the destroyed WebView. - On the Tizen 10.0 TV emulator (TV_PROFILE + x86_64), hide the stopped view instead of deleting it to avoid a SIGSEGV in chromium-efl's ~SelectionControllerEfl(); revert once the engine fix ships. Verified on the TV 10.0 emulator: example integration tests previously crashed on WebView disposal and now pass 19/19.
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
2 participants
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.
UnregisterTexture() previously destroyed the ExternalTexture (running glDeleteTextures) synchronously on the calling platform thread. That could race with an in-flight PopulateGLTexture() on the render thread and free the backing TBM buffer while the GPU still referenced it, causing heap corruption and "tbm_bo_free ... lock_cnt" crashes on the SW backend.