Bug 90821

Summary: Segfault when calling glViewport on surfaceless EGL context without bound FBO
Product: Mesa Reporter: Martina Kollarova <martina.kollarova>
Component: EGLAssignee: mesa-dev
Status: RESOLVED DUPLICATE QA Contact: mesa-dev
Severity: normal    
Priority: medium CC: philip+freedesktop, tworaz666
Version: git   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: glxinfo
output on both Linux and ChromeOS

Description Martina Kollarova 2015-06-02 14:51:24 UTC
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
Comment 1 Martina Kollarova 2015-06-04 12:54:54 UTC
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.
Comment 2 Martina Kollarova 2015-06-04 13:00:55 UTC
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.
Comment 3 Matt Turner 2015-06-04 16:17:47 UTC
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
Comment 4 Philip Derrin 2015-07-06 08:07:11 UTC
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.
Comment 5 Nanley Chery 2015-12-09 19:20:34 UTC

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