[vbox-dev] Chromium WindowDestroy

[Chris Smowton]

Hey all,

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 
questions are:

* 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?

Chris