It's not possible for unity or mir to help with the cleanup as the
window surface is a purely client side object owned by the egl layer.
For example, if an app calls outside of the emulator eglCreateContext
and then crashes there is no leak, any hardware side resources would be
cleaned up by the kernel component of the driver.

Thus I propose the bug as in the emulator, perhaps it is present in
android even (but they dont go around SIGKILLING things randomly). It's
also possible that android worked around it in some weird way (i.e.
unload hook in EGL library...is enough to save you from SIGTERM anyway).

I don't understand the entire architecture of the emulator but if you
look in sdk/emulator/opengl/host/libs/libOpenglRender/RenderThread.cpp I
have a plausible guess. You can see at the bottom:
FrameBuffer::getFb()->bindContext(...blabla, to attempt to release
references to the current threads context/surfaces. However quick
inspection of FrameBuffer.cpp shows this is not enough, m_windows
contains a strong reference to the WindowSurface (created by the protocl
interpreter through CreateWindowSurface). I think prior to this
bindContext operation we need to call FrameBuffer::desroyWindowSurface,
DestroyRenderContext, etc, using the values from RenderThreadInfo. Ill
figure out how to build the emulator and test this theory...

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1319582

Title:
  emulator: 'Failed to start RenderThread' after opening/closing
  applications

To manage notifications about this bug go to:
https://bugs.launchpad.net/mir/+bug/1319582/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to