ASSERTION: Error setting up framebuffer.: 'mGLContext->fCheckFramebufferStatus(LOCAL_GL_FRAMEBUFFER) == LOCAL_GL_FRAMEBUFFER_COMPLETE'




9 years ago
8 years ago


(Reporter: romaxa, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(2 attachments, 3 obsolete attachments)



9 years ago
I'm using latest trunk (mc:a2f52283e534) + cjones mcmq[400:f9db15e5e074] + patch from (EGL image fallback)

and have this error:
Extensions: EGL_KHR_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_vg_parent_image EGL_NOKIA_texture_from_pixmap 0x45
Extensions length: 158
Initializing context 0x487912c0 surface (nil) on display 0x2
GL extensions: GL_OES_rgb8_rgba8 GL_OES_depth24 GL_OES_vertex_half_float GL_OES_texture_float GL_OES_texture_half_float GL_OES_element_index_uint GL_OES_mapbuffer GL_OES_fragment_precision_high GL_OES_compressed_ETC1_RGB8_texture GL_OES_EGL_image GL_EXT_multi_draw_arrays GL_IMG_shader_binary GL_IMG_texture_compression_pvrtc GL_IMG_texture_stream2 GL_IMG_texture_npot 
Found extension GL_OES_depth24
OpenGL vendor recognized as: <other>
###!!! ASSERTION: does it make sense to Resize() a disabled or hidden widget?: 'mEnabled && mVisible', file widget/src/xpwidgets/PuppetWidget.cpp, line 182
###!!! ASSERTION: does it make sense to Resize() a disabled or hidden widget?: 'mEnabled && mVisible', file widget/src/xpwidgets/PuppetWidget.cpp, line 182
GL ERROR: 0x0501 at gfx/layers/opengl/LayerManagerOGL.cpp:559
###!!! ASSERTION: Error setting up framebuffer.: 'mGLContext->fCheckFramebufferStatus(LOCAL_GL_FRAMEBUFFER) == LOCAL_GL_FRAMEBUFFER_COMPLETE', file gfx/layers/opengl/LayerManagerOGL.cpp, line 905
GL ERROR: 0x0501 at gfx/layers/opengl/LayerManagerOGL.cpp:910
GL ERROR: 0x0506 at gfx/layers/opengl/ThebesLayerOGL.cpp:711
GL ERROR: 0x0506 at gfx/layers/opengl/ThebesLayerOGL.cpp:110
###!!! ASSERTION: Error setting up framebuffer.: 'mGLContext->fCheckFramebufferStatus(LOCAL_GL_FRAMEBUFFER) == LOCAL_GL_FRAMEBUFFER_COMPLETE', file gfx/layers/opengl/LayerManagerOGL.cpp, line 905
GL ERROR: 0x0501 at gfx/layers/opengl/LayerManagerOGL.cpp:910
GL ERROR: 0x0506 at gfx/layers/opengl/ThebesLayerOGL.cpp:711
GL ERROR: 0x0506 at gfx/layers/opengl/ThebesLayerOGL.cpp:110

Any ideas why it happen?

Comment 1

9 years ago
aah, I'm using Qt build on Maemo5.
and opening MOZ_ACCELERATED=1 ./fennec -url file:///usr/share

after this run device in ~95% cases need reboot, because driver dead after launching mozilla
OS: Linux → Maemo
Hardware: x86 → ARM

Comment 2

9 years ago
UI rendered, content not rendered.
about:license page rendered somehow, but device dead almost immediately after that...

Also with about:license page (local page) those GL errors not reproducible anymore

Comment 3

9 years ago
Tested on latest GTK maemo5 with MOZ_ACCELERATED=1 enabled
5  0x40a94adc in mozilla::gl::GLContext::fCheckFramebufferStatus (this=0x48e1dc00, target=36160) at ../../../dist/include/GLContext.h:1822
#6  0x4177a554 in mozilla::gl::GLContext::SetBlitFramebufferForDestTexture (this=0x48e1dc00, aTexture=2450035) at gfx/thebes/GLContext.cpp:1684
#7  0x4177a838 in mozilla::gl::GLContext::BlitTextureImage (this=0x48e1dc00, aSrc=0x4a239520, aSrcRect=..., aDst=0x48e4f040, aDstRect=...)
    at gfx/thebes/GLContext.cpp:1190
#8  0x417b1028 in mozilla::layers::BasicBufferOGL::BeginPaint (this=0x4d894d30, aContentType=145) at gfx/layers/opengl/ThebesLayerOGL.cpp:432
#9  0x417b1824 in mozilla::layers::ThebesLayerOGL::RenderLayer (this=0x46fb7f80, aPreviousFrameBuffer=0, aOffset=...)
    at gfx/layers/opengl/ThebesLayerOGL.cpp:548
#10 0x417a59f4 in mozilla::layers::ContainerLayerOGL::RenderLayer (this=0x46362aa0, aPreviousFrameBuffer=0, aOffset=...)
    at gfx/layers/opengl/ContainerLayerOGL.cpp:253
#11 0x417ab7c8 in mozilla::layers::LayerManagerOGL::Render (this=0x48b8bb40) at gfx/layers/opengl/LayerManagerOGL.cpp:605
#12 0x417ac1d0 in mozilla::layers::LayerManagerOGL::EndTransaction (this=0x48b8bb40, 
    aCallback=0x407068fc <mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*)>, aCallbackData=0xbefde1f8)
    at gfx/layers/opengl/LayerManagerOGL.cpp:421
#13 0x407431c8 in nsDisplayList::PaintForFrame (this=<value optimized out>, aBuilder=0xbefde1f8, aCtx=<value optimized out>, aForFrame=<value optimized out>, aFlags=3204309440)
    at layout/base/nsDisplayList.cpp:495
#14 0x407434f4 in nsDisplayList::PaintRoot (this=<value optimized out>, aBuilder=0x0, aCtx=<value optimized out>, aFlags=<value optimized out>)
    at layout/base/nsDisplayList.cpp:402
#15 0x40763e24 in nsLayoutUtils::PaintFrame (aRenderingContext=0x4, aFrame=0x479306d8, aDirtyRegion=..., aBackstop=1153673248, aFlags=0)
    at layout/base/nsLayoutUtils.cpp:146

Comment 4

9 years ago
Ok problems here is because of Texture Resize seems does not do exactly what blit functionality expecting...

  // a) Create texture ID
  GLuint texture;
  glGenTextures(1, &texture);
  glBindTexture(GL_TEXTURE_2D, texture);

  // b) Bind to X-Pixmap
  Pixmap pixmap = createNew16BppX-Pixmap;
  khrimage = eglCreateImageKHR(dpy, EGL_NO_CONTEXT, EGL_NATIVE_PIXMAP_KHR, pixmap, NULL);
  glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, khrimage);

   // c) Bind framebuffer to texture
   glGenFramebuffers(1, &mBlitFramebuffer);
   glBindFramebuffer(GL_FRAMEBUFFER, mBlitFramebuffer);

    if (glCheckFramebufferStatus(LOCAL_GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE) {
with this code we always have error printed...

If I call between a) and b) glTexImage2D (...., size), still have EERRRORR
If I call between b) and c) glTexImage2D (...., size), I don't have error, but texture seems disconnected from pixmap, and lock/unlock does not work anymore...

If I replace b) with glTexImage2D (...., size),  and do work with glTexImage2D only , then everything works fine.. (same as no backingSurface code)


9 years ago
Blocks: 625939

Comment 5

9 years ago
Answer from Nokia Graphics drivers developers:
I think the error you are getting is being triggered here. The problem is that 
the driver does not support making a connection through EGLImage => texture => 
framebuffer object. Instead, you should skip the texture completely and bind 
the EGLImage to a renderbuffer instead:

glGenRenderbuffers(1, &renderbuffer);
glBindRenderbuffer(GL_RENDERBUFFER, renderbuffer);
glEGLImageTargetRenderbufferStorageOES(GL_RENDERBUFFER, image);

glGenFramebuffers(1, &mBlitFramebuffer);
glBindFramebuffer(GL_FRAMEBUFFER, mBlitFramebuffer);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, 
                          GL_RENDERBUFFER, renderbuffer);

adding myself
Posted patch use rbo to blit (obsolete) — Splinter Review
Here's a first somewhat working version. I delete the texture before attaching a renderbuffer to the image, maybe this isn't really necessary. Also, sometimes I get black regions.
this doesn't show the black bars and at least buffers the eglImage between rbo creation and destruction
Attachment #504701 - Attachment is obsolete: true
Nokia driver guys tell me you can have *both* a Texture and a Renderbuffer attached. This gives this simplified patch. I can sometimes trigger a segfault maybe a race condition to be solved with a EGL fence.

Program received signal SIGSEGV, Segmentation fault.
gfxContext::gfxContext (this=0x438d0a90, surface=0x0) at /home/fhae/upstream/mozilla-central/gfx/thebes/gfxContext.cpp:64
64      /home/fhae/upstream/mozilla-central/gfx/thebes/gfxContext.cpp: No such file or directory.                        
        in /home/fhae/upstream/mozilla-central/gfx/thebes/gfxContext.cpp                                                 
(gdb) bt                                                                                                                 
#0  gfxContext::gfxContext (this=0x438d0a90, surface=0x0) at /home/fhae/upstream/mozilla-central/gfx/thebes/gfxContext.cpp:64
#1  0x3bdaaf48 in mozilla::gl::TextureImageEGL::BeginUpdate (this=0x451e9d00, aRegion=...) at /home/fhae/upstream/mozilla-central/gfx/thebes/GLContextProviderEGL.cpp:1099
#2  0x3bdcc3e8 in mozilla::layers::BasicBufferOGL::BeginPaint (this=<value optimized out>, aContentType=<value optimized out>) at /home/fhae/upstream/mozilla-central/gfx/layers/opengl/ThebesLayerOGL.cpp:463
Posted patch delete rboSplinter Review
This fixes crashes for me - apparently you run out of memory after some time because we create and destroy eglImages constantly during scrolling and I didn't delete the renderbuffer object.
Attachment #504735 - Attachment is obsolete: true
Attachment #505036 - Attachment is obsolete: true


8 years ago
Attachment #505794 - Flags: feedback?(jmuizelaar)

Comment 11

8 years ago
I've tested it on Maemo5 and it does not work, because HasKHRImageTexture2D and HasKHRImagePixmap - false there...

I think we should do something in Else condition
I put this into BlitTextureImage and it seems to look okay:

nsRefPtr<gfxASurface> s = aSrc->GetBackingSurface();
nsIntRegion dReg(aDstRect); //might be modified by beginupdate
nsRefPtr<gfxASurface> d = aDst->BeginUpdate(dReg);
nsIntRect dRect=dReg.GetBounds();

nsRefPtr<gfxContext> ctx = new gfxContext(d);
gfxUtils::ClipToRegion(ctx, nsIntRegion(dRect));
nsIntPoint o=aDstRect.TopLeft() - aSrcRect.TopLeft();
ctx->SetSource(s, gfxPoint(o.x,o.y));

fennec looks weird on my n900 even without the patch, I get stray white or black pixels almost everywhere. Also it is quite slow, no Idea whats up with that. What do you think? This is basically a software blit, right?
Posted patch rebasedSplinter Review
This is just the same patch, rebased against current mozilla-central
I am getting the same error on a Nexus S, so there is a non-Nokia-specific problem around here. See bug 628566 comment 20.
Just realized that the patch is has some Maemo/X11-specific code... trying to port it to Android at the moment.
Comment on attachment 505794 [details] [diff] [review]
delete rbo

Setting feedback- because this patch actually *creates* this bug on Android.

In other words:

              | Maemo | Android |
Without patch | Bad   | Good    |
With patch    | Good  | Bad     |

The reason for this bug on Android seems that it *might* be that when BindToFramebuffer binds the texture as color attachment of a framebuffer, it results in the framebuffer having only a color attachment and no depth buffer attachment. If that is the case, then the fix would be to attach a renderbuffer as depth attachment.
Attachment #505794 - Flags: feedback?(jmuizelaar) → feedback-
You need to log in before you can comment on or make changes to this bug.