[vbox-dev] Chromium WindowDestroy
cs448 at cam.ac.uk
Sat Oct 17 00:33:18 PDT 2009
I'm currently trying to adapt VBox's Chromium code for another VMM; thus
far this is going very well, to the point that I can host multiple apps
for multiple guests and compose them with the guest's 2D output; however
I've hit a small snag:
If a guest terminates unexpectedly (e.g. I just ctrl-C a running GL
program), the server sees the connection die, as expected. Then...
* The server destroys all that client's windows. On a Linux guest, this
ends up in renderspu_SystemDestroyWindow, which under X zaps the host
window. So far, so good.
* The server destroys all that client's contexts. Similar process to
above, but here we notice that this context is current, so Chromium
tries to CrMakeCurrent the dummy context. Since this is Chromium, that's
not a proper "glxMakeCurrent" on the local system, but rather
state_diff's selective setting of the current context's properties.
Unfortunately, one of those is setting the viewport -- which entails a
call to the local GL's glViewport -- which issues an XGeometery request,
against the local window -- but oh dear, that's the window we zapped in
the previous step.
The result is that crserver dies due to an X error.
In this case, this could be trivially solved by reversing the order of
context and window destruction; the context-kill would go through fine,
then the window-destroy would be our last action. However this isn't a
very good solution, as the guest could send an explicit destory-window
followed by destroy-context.
I think the right thing to do here is to react to a destroy-window
affecting our current local target window by doing a real
glxMakeCurrent(d, null, null), which would properly release the window
from the local libGL's clutches, and mean that the context switch (and
any other ops which cause X requests in libGL or elsewhere) to go
through. I *think* that won't be a problem, as on our next run through
the message-dispatch loop we'll run SystemMakeCurrent, and any ops on
behalf of the same client are invalid in this situation and should be
dropped anyway, as you shouldn't run any GL commands without a current
context, and shouldn't destroy a window without MakeCurrent(dis, 0,
0)'ing first so you don't try to operate on a bad X resource.
However, this is Chromium, so odds on I'm missing something -- so my
* Has anyone hit this particular issue before? If so, what did they do?
* Does my plan above sound sane? Any suggestions?
* What's the proper way to set the system context (i.e. really run
glxMakeCurrent) without introducing inconsistencies in server state?
More information about the vbox-dev