gpu: Bind dummy GL API when no context is current

content/common/gpu/texture_image_transport_surface.cc

Index: content/common/gpu/texture_image_transport_surface.cc
diff --git a/content/common/gpu/texture_image_transport_surface.cc b/content/common/gpu/texture_image_transport_surface.cc
index 45ce615c4951ca37627558a6e40d23c037acc788..413d1d4d636770a212bfd4c5618d39143e53b743 100644
--- a/content/common/gpu/texture_image_transport_surface.cc
+++ b/content/common/gpu/texture_image_transport_surface.cc
@@ -30,8 +30,7 @@ namespace content {
 namespace {
 
 bool IsContextValid(ImageTransportHelper* helper) {
-  return helper->stub()->decoder()->GetGLContext()->IsCurrent(NULL) ||
-      helper->stub()->decoder()->WasContextLost();
+  return helper->stub()->decoder()->GetGLContext()->IsCurrent(NULL);
 }
 
 }  // namespace
@@ -175,19 +174,26 @@ void TextureImageTransportSurface::OnResize(gfx::Size size,
 }
 
 void TextureImageTransportSurface::OnWillDestroyStub() {
-  DCHECK(IsContextValid(helper_.get()));
+  bool have_context = IsContextValid(helper_.get());
   helper_->stub()->RemoveDestructionObserver(this);
 
   // We are losing the stub owning us, this is our last chance to clean up the
   // resources we allocated in the stub's context.
-  ReleaseBackTexture();
-  ReleaseFrontTexture();
+  if (have_context) {
+    ReleaseBackTexture();
+    ReleaseFrontTexture();
+  } else {

[piman, 2014/04/01 23:00:02]

It's not specific to this change, but this makes me think we may be leaking
resources if we lose contexts for non-GL reasons. Could you file a bug for this,
referencing this CL?

[no sievers, 2014/04/01 23:39:37]

In the stack from 355275 we are not leaking because it's called from
GpuChannelManager::OnLoseAllContexts().

We also wouldn't be leaking textures in case the context is lost because of a
parse error, because GpuCommandBufferStub::Destroy() wil still try to make the
decoder's context + surface current before calling OnWillDestroyStub().

So we could only leak if
- we don't lose the whole share group when losing contexts
- we cannot make the lost context current at all during cleanup
- there is still another context around that references the share group

[piman, 2014/04/01 23:50:58]

Only if the context isn't know to be lost, though. E.g. if the client calls
LoseContextCHROMIUM (e.g on GL_OUT_OF_MEMORY with Dana's patch), we'd set the
kLostContext state even though GL isn't lost.
That loses the whole ContextGroup, but not the whole GLShareGroup

+    backbuffer_ = NULL;
+    back_mailbox_ = Mailbox();
+    frontbuffer_ = NULL;
+    front_mailbox_ = Mailbox();
+  }
 
-  if (fbo_id_) {
+  if (fbo_id_ && have_context) {
     glDeleteFramebuffersEXT(1, &fbo_id_);
     CHECK_GL_ERROR();
-    fbo_id_ = 0;
   }
+  fbo_id_ = 0;
 
   stub_destroyed_ = true;
 }