Created attachment 116246 [details] glxinfo The glViewport command creates a segfault when called without a bound FBO on a surfaceless EGL context, even tough GL_OES_surfaceless_contex and EGL_KHR_surfaceless_contex are supported. This ocurred in Chromium [1][2]. A possible way to reproduce it in Chromium (without using egltest, which is a bit flaky), is to just add `glViewport(0,0,0,0)` to gl_surface_egl.cc:378 [3] and run `chrome --use-gl=egl --in-process-gpu` - a backtrace of this is at the end of this message. I can try to create a simpler reproducer outside of Chromium. I reproduced this in Linux with Mesa 10.7.0-devel (git-6cdb29d 2015-05-21 trusty-oibaf-ppa) and a colleague reproduced it with Mesa 10.5.2 (using the same hardware). However, he couldn't reproduce it on ChromeOS (mesa-10.3-r33) and Yocto (mesa-10.5.4). [1] https://code.google.com/p/chromium/issues/detail?id=462948 [2] https://codereview.chromium.org/207443007/ [3] https://code.google.com/p/chromium/codesearch#chromium/src/ui/gl/gl_surface_egl.cc&q=gl_surface_e&sq=package:chromium&l=378 #0 0x00007fffcffe02b1 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #1 0x00007fffd002d141 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #2 0x00007fffeeb32d02 in gfx::GLApiBase::glViewportFn (this=0x300e18765da0, x=0, y=0, width=0, height=0) at ../../ui/gl/gl_bindings_autogen_gl.cc:7561 #3 0x00007fffeeb931ce in gfx::GLSurfaceEGL::InitializeOneOff () at ../../ui/gl/gl_surface_egl.cc:382 #4 0x00007fffeeb76040 in gfx::GLSurface::InitializeOneOffInternal () at ../../ui/gl/gl_surface_x11.cc:67 #5 0x00007fffeeb719e1 in gfx::GLSurface::InitializeOneOffImplementation (impl=gfx::kGLImplementationEGLGLES2, fallback_to_osmesa=false, gpu_service_logging=false, disable_gl_drawing=false) at ../../ui/gl/gl_surface.cc:79 #6 0x00007fffeeb7195e in gfx::GLSurface::InitializeOneOff () at ../../ui/gl/gl_surface.cc:70 #7 0x00007ffff07e93d9 in content::GpuChildThread::GpuChildThread (this=0x300e18735b20, params=..., __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at ../../content/gpu/gpu_child_thread.cc:97 #8 0x00007ffff07f0453 in content::InProcessGpuThread::Init (this=0x300e1835e3e0) at ../../content/gpu/in_process_gpu_thread.cc:26 #9 0x00007ffff5ad0c9a in base::Thread::ThreadMain (this=0x300e1835e3e0) at ../../base/threading/thread.cc:239 #10 0x00007ffff5abe717 in base::(anonymous namespace)::ThreadFunc (params=0x7fffd63bb860) at ../../base/threading/platform_thread_posix.cc:77 #11 0x00007fffe8a68182 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #12 0x00007fffe879547d in clone () from /lib/x86_64-linux-gnu/libc.so.6
Reproducer: https://github.com/mkollaro/opengl_snippets/blob/master/egl/main.cpp Compile with: gcc main.cpp -std=c++11 -lEGL -lGLESv2 It will segfault if the bug is present, print "Success" on the last line if not. Reproduced on Linux Mint 17.1 Rebecca (based on Ubuntu Trusty) with Mesa 10.7.0-devel and Ubuntu 15.04 with Mesa 10.5.2. Could not reproduce on ChromeOS with Mesa 10.3r33. The Yocto setup is currently unavailable. You can additionally add "-DNO_SURFACE=false" and it will use a pbuffer surface, where the segfault doesn't occur.
Created attachment 116287 [details] output on both Linux and ChromeOS Correction: The ChromeOS setup (where the bug doesn't reproduce) didn't use Mesa 10.3r33, but 10.5.0-devel.
Indeed, I can reproduce on master using your test program (thanks a lot for that!) Program received signal SIGSEGV, Segmentation fault. 0x00007ffff4e1ad42 in dri2InvalidateDrawable (drawable=0x0) at ../../../../../../mesa/src/mesa/drivers/dri/common/dri_util.c:798 798 drawable->dri2.stamp++; (gdb) bt #0 0x00007ffff4e1ad42 in dri2InvalidateDrawable (drawable=0x0) at ../../../../../../mesa/src/mesa/drivers/dri/common/dri_util.c:798 #1 0x00007ffff4e382b5 in intel_viewport (ctx=0x7ffff7fcf040) at ../../../../../../mesa/src/mesa/drivers/dri/i965/brw_context.c:155 #2 0x00007ffff4b9f405 in _mesa_Viewport (x=0, y=0, width=0, height=0) at ../../../mesa/src/mesa/main/viewport.c:125 #3 0x00000000004014f4 in main (argc=1, argv=0x7fffffffe148) at main.cpp:180
I encountered this too, on i965. It happens because intel_viewport calls _mesa_is_winsys_fbo to determine whether the draw buffer has an associated DRI2 drawable, but that predicate returns true for the global IncompleteFramebuffer which is used by surfaceless contexts, which obviously has no DRI2 drawable. A null pointer check in intel_viewport fixes it. The i915 driver looks like it has the same problem (in intel_invalidate_viewport), though I haven't tested it.
*** This bug has been marked as a duplicate of bug 93257 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.