[Mesa-dev] [Bug 104196] XOrg fails to start due to Mesa DRI crash with NULL pointer, also glmark2 fails with NULL pointer

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sun Dec 10 18:21:40 UTC 2017


https://bugs.freedesktop.org/show_bug.cgi?id=104196

            Bug ID: 104196
           Summary: XOrg fails to start due to Mesa DRI crash with NULL
                    pointer, also glmark2 fails with NULL pointer
           Product: Mesa
           Version: 17.3
          Hardware: All
                OS: Linux (All)
            Status: NEW
          Severity: critical
          Priority: medium
         Component: glsl-compiler
          Assignee: mesa-dev at lists.freedesktop.org
          Reporter: luis.p.mendes at gmail.com
        QA Contact: intel-3d-bugs at lists.freedesktop.org

Summary:
After upgrade from mesa-17.2.5 to mesa-17.3.0 XOrg fails to start, crashing
with a NULL pointer on mesa, also glmark2 fails with a SIGSEGV due to a NULL
pointer when it reaches the [buffer]
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map
test.

Details:
The problem was first introduced on mesa version 17.3.0-rc3 with patch provided
in commit a12ca3b231a6454d8adf5da916af363c321b5f1a, "disk_cache: Fix issue
reading GLSL metadata".

Reverting this patch allows XOrg to start normally and glmark2 to complete all
tests.

A sample stack trace from mesa when glmark2/XOrg fails is as follows:
[desktop] effect=shadow:windows=4: FPS: 991 FrameTime: 1.009 ms
[New Thread 0xb11ff440 (LWP 4764)]
[Thread 0xb09ff440 (LWP 4763) exited]

Thread 1 "glmark2" received signal SIGSEGV, Segmentation fault.
strcmp () at ../sysdeps/arm/armv7/strcmp.S:181
181     ../sysdeps/arm/armv7/strcmp.S: No such file or directory.
(gdb) bt
#0  strcmp () at ../sysdeps/arm/armv7/strcmp.S:181
#1  0xb6290dd4 in read_buffer_block (metadata=metadata at entry=0xbeffea8c, 
    b=0xafd5f020, prog=<optimized out>)
    at ../../../src/compiler/glsl/shader_cache.cpp:383
#2  0xb62924d8 in read_buffer_blocks (prog=0x12bd00, metadata=0xbeffea8c)
    at ../../../src/compiler/glsl/shader_cache.cpp:410
#3  shader_cache_read_program_metadata (ctx=0x349e10, prog=<optimized out>)
    at ../../../src/compiler/glsl/shader_cache.cpp:1553
#4  0xb6236760 in link_shaders (ctx=ctx at entry=0x349e10, 
    prog=prog at entry=0x12bd00) at ../../../src/compiler/glsl/linker.cpp:4725
#5  0xb61bb024 in _mesa_glsl_link_shader (ctx=ctx at entry=0x349e10, 
    prog=prog at entry=0x12bd00) at ../../../src/mesa/program/ir_to_mesa.cpp:3109
#6  0xb6123018 in link_program (no_error=<optimized out>, 
    shProg=<optimized out>, ctx=<optimized out>)
    at ../../../src/mesa/main/shaderapi.c:1171
#7  link_program_error (ctx=0x349e10, shProg=0x12bd00)
    at ../../../src/mesa/main/shaderapi.c:1249
#8  0xb6123202 in _mesa_LinkProgram (programObj=<optimized out>)
    at ../../../src/mesa/main/shaderapi.c:1741
#9  0xb6e33470 in glLinkProgram (program=<optimized out>)
    at ../../../src/mapi/glapi/glapi_mapi_tmp.h:6273
#10 0x0009cd66 in ?? ()
#11 0x000950c4 in ?? ()
...
(gdb) up
#1  0xb6290dd4 in read_buffer_block (metadata=metadata at entry=0xbeffea8c, 
    b=0xafd5f020, prog=<optimized out>)
    at ../../../src/compiler/glsl/shader_cache.cpp:383
383     ../../../src/compiler/glsl/shader_cache.cpp: No such file or directory.
code: if (strcmp(b->Uniforms[j].Name, index_name) == 0) {
(gdb) print b
$1 = (gl_uniform_block *) 0xafd5f020
(gdb) print j         
$2 = 37
(gdb) print b->Uniforms[j].IndexName
$3 = 0x0
(gdb) print index_name
$4 = 0x0
(gdb) print b->Name
$5 = 0x2bdd80 ""

As it can be seen the strcmp fails with a SIGSEGV when de-referencing either
index_name or b->Uniforms[j].Name, but the problem is introduced by the
identified patch above.

Could it be that num_keys is zero sometimes while there is at least one
cache_key structure available?

How to reproduce:
glmark2 - To reproduce the glmark2 issue upgrade the mesa version with X
already running and then run glmark2 after the mesa upgrade.

XOrg - Install glmark2 and reboot or restart X.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171210/3a65fba2/attachment.html>


More information about the mesa-dev mailing list