Bug 107782 - SIGSEGV in intelCreateBuffer(intel_screen.c) when using EGL_KHR_gl_colorspace
Summary: SIGSEGV in intelCreateBuffer(intel_screen.c) when using EGL_KHR_gl_colorspace
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Tapani Pälli
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-02 15:07 UTC by Elias Naur
Modified: 2019-09-25 19:13 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
test program (7.15 KB, text/x-csrc)
2018-09-02 15:07 UTC, Elias Naur
Details
glxinfo (28.09 KB, text/plain)
2018-09-08 10:46 UTC, Elias Naur
Details

Description Elias Naur 2018-09-02 15:07:47 UTC
Created attachment 141413 [details]
test program

I'm running the attached example on Ubuntu 18.04.01 where I'm trying to create an OpenGL ES 3 context with EGL where the framebuffer supports sRGB. When using the EGL_KHR_gl_colorspace extension attributes for eglCreateWindowSurface, the call crashes.

Compiled with:

gcc -o test init_window.c -I. -lwayland-client -lwayland-server -lwayland-egl -lEGL -lGLESv2

The gdb backtrace:

Program received signal SIGSEGV, Segmentation fault.
intelCreateBuffer (dri_screen=0x5555557873e0, driDrawPriv=0x5555558a2950, mesaVis=0x0, isPixmap=0 '\000')
    at ../../../../../../src/mesa/drivers/dri/i965/intel_screen.c:1615
1615	../../../../../../src/mesa/drivers/dri/i965/intel_screen.c: No such file or directory.
=> 0x00007ffff367babb <intelCreateBuffer+27>:	8b 72 78	mov    0x78(%rdx),%esi
   0x00007ffff367babe <intelCreateBuffer+30>:	48 89 ef	mov    %rbp,%rdi
   0x00007ffff367bac1 <intelCreateBuffer+33>:	e8 aa 83 ff ff	callq  0x7ffff3673e70 <intel_quantize_num_samples>
(gdb) bt
#0  intelCreateBuffer (dri_screen=0x5555557873e0, driDrawPriv=0x5555558a2950, mesaVis=0x0, isPixmap=0 '\000')
    at ../../../../../../src/mesa/drivers/dri/i965/intel_screen.c:1615
#1  0x00007ffff3611957 in driCreateNewDrawable (screen=0x5555557873e0, config=0x0, data=0x5555558a5ce0)
    at ../../../../../../src/mesa/drivers/dri/common/dri_util.c:695
#2  0x00007ffff64a9c27 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0
#3  0x00007ffff6496aa7 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0
#4  0x00005555555557c0 in CreateEGLContext ()
#5  0x0000555555555931 in CreateWindowWithEGLContext ()
#6  0x0000555555555c27 in main ()

and the top of the disassembly:

(gdb) disas
Dump of assembler code for function intelCreateBuffer:
   0x00007ffff367baa0 <+0>:	push   %r15
   0x00007ffff367baa2 <+2>:	push   %r14
   0x00007ffff367baa4 <+4>:	push   %r13
   0x00007ffff367baa6 <+6>:	push   %r12
   0x00007ffff367baa8 <+8>:	mov    %rsi,%r13
   0x00007ffff367baab <+11>:	push   %rbp
   0x00007ffff367baac <+12>:	push   %rbx
   0x00007ffff367baad <+13>:	mov    %ecx,%r12d
   0x00007ffff367bab0 <+16>:	mov    %rdx,%rbx
   0x00007ffff367bab3 <+19>:	sub    $0x18,%rsp
   0x00007ffff367bab7 <+23>:	mov    0x10(%rdi),%rbp
=> 0x00007ffff367babb <+27>:	mov    0x78(%rdx),%esi
   0x00007ffff367babe <+30>:	mov    %rbp,%rdi
   0x00007ffff367bac1 <+33>:	callq  0x7ffff3673e70 <intel_quantize_num_samples>
   ...


The offending code is:

   EGLint surfaceAttribs[] = { EGL_GL_COLORSPACE_KHR, EGL_GL_COLORSPACE_SRGB_KHR, EGL_NONE, EGL_NONE };
   // Create a surface
   surface = eglCreateWindowSurface(display, config, ESContext.native_window, surfaceAttribs);

If I replace EGL_GL_COLORSPACE_SRGB_KHR with EGL_GL_COLORSPACE_LINEAR_KHR, a window is displayed with a clear color and no crashes.

My system details (a Lenovo X1 Carbon 1st gen.):

$ uname -a
Linux elias-x1 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.1 LTS
Release:	18.04
Codename:	bionic

The list of extensions as reported by eglGetString(EGL_EXTENSIONS). Note that EGL_KHR_gl_colorspace is included:

EGL_ANDROID_native_fence_sync EGL_CHROMIUM_sync_control EGL_EXT_buffer_age EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_image_dma_buf_export EGL_NOK_texture_from_pixmap EGL_WL_bind_wayland_display

The reported EGL version is 1.4.

The display section from lshw:

        *-display
             description: VGA compatible controller
             product: 3rd Gen Core processor Graphics Controller
             vendor: Intel Corporation
             physical id: 2
             bus info: pci@0000:00:02.0
             version: 09
             width: 64 bits
             clock: 33MHz
             capabilities: vga_controller bus_master cap_list rom
             configuration: driver=i915 latency=0
             resources: irq:28 memory:f0000000-f03fffff memory:e0000000-efffffff ioport:5000(size=64) memory:c0000-dffff


I would expect that

(1) An error from eglCreateWindowSurface, not a crash
(2) The EGL_KHR_gl_colorspace extension not be included in EGL_EXTENSIONS if it can't be supported.

and, if possible,

(3) Support for OpenGL surfaces with a sRGB framebuffer created through EGL on Wayland. Note that the hardware reports GLX_ARB_framebuffer_sRGB for GLX.
Comment 1 Tapani Pälli 2018-09-03 05:22:42 UTC
You should be getting EGL_BAD_MATCH from eglCreateWindowSurface, this is what I get when running similar test utilizes Xlib/EGL.
Comment 2 Tapani Pälli 2018-09-03 08:20:14 UTC
Can you please include your Mesa version (or full output of glxinfo)?
Comment 3 Tapani Pälli 2018-09-04 11:51:35 UTC
Please check if setting EGL_ALPHA_SIZE to 8 in fbAttribs fixes the issue, AFAIK this way EGL_GL_COLORSPACE_SRGB_KHR should work. The reason is that we state sRGB support for all but truth is we support it only with B8G8R8A8 (and on Android R8G8B8A8).
Comment 4 Elias Naur 2018-09-08 10:45:43 UTC
Adding EGL_ALPHA_SIZE=8 to the eglChooseConfig attributes worked. There is no crash, and sRGB textures look right when rendered to the window.

Not crashing when EGL_ALPHA_SIZE is unspecified is would be nice though. I have attached the full output of glxinfo in case my Mesa version is older than a fix that went in later.

It would be even nicer if eglCreateWindowSurface wouldn't return EGL_BAD_MATCH for configs without EGL_ALPHA_SIZE specified. But perhaps that's a hardware limitation?
Comment 5 Elias Naur 2018-09-08 10:46:13 UTC
Created attachment 141480 [details]
glxinfo
Comment 6 Elias Naur 2018-09-08 11:13:52 UTC
Note that the glxinfo output is from a different machine that exhibits the same crash, a Fedora 28 with the following Intel graphics device:

        *-display
             description: VGA compatible controller
             product: HD Graphics 530
             vendor: Intel Corporation
             physical id: 2
             bus info: pci@0000:00:02.0
             version: 06
             width: 64 bits
             clock: 33MHz
             capabilities: vga_controller bus_master cap_list rom
             configuration: driver=i915 latency=0
             resources: irq:133 memory:dd000000-ddffffff memory:b0000000-bfffffff ioport:f000(size=64) memory:c0000-dffff
Comment 7 Tapani Pälli 2018-10-04 08:05:43 UTC
(In reply to Elias Naur from comment #4)
> Adding EGL_ALPHA_SIZE=8 to the eglChooseConfig attributes worked. There is
> no crash, and sRGB textures look right when rendered to the window.
> 
> Not crashing when EGL_ALPHA_SIZE is unspecified is would be nice though. I
> have attached the full output of glxinfo in case my Mesa version is older
> than a fix that went in later.
> 
> It would be even nicer if eglCreateWindowSurface wouldn't return
> EGL_BAD_MATCH for configs without EGL_ALPHA_SIZE specified. But perhaps
> that's a hardware limitation?

That would need some tinkering in the driver, I think it should be possible for us to expose sRGB capable RGBX visuals but .. risky. Every time we change the visuals, some of the supported desktops (gnome/kde) tend to break. Let's leave this bug open as a 'feature request/reminder' for this to happen. There's also bug #92759 referring to the same issue.
Comment 8 GitLab Migration User 2019-09-25 19:13:27 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1752.


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.