Bug 104196

Summary: XOrg fails to start due to Mesa DRI crash with NULL pointer, also glmark2 fails with NULL pointer
Product: Mesa Reporter: Luis Mendes <luis.p.mendes>
Component: glsl-compilerAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: critical    
Priority: medium    
Version: 17.3   
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Luis Mendes 2017-12-10 18:21:40 UTC
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@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@entry=0x349e10, 
    prog=prog@entry=0x12bd00) at ../../../src/compiler/glsl/linker.cpp:4725
#5  0xb61bb024 in _mesa_glsl_link_shader (ctx=ctx@entry=0x349e10, 
    prog=prog@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@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.
Comment 1 Luis Mendes 2017-12-27 19:56:35 UTC
This bug no longer occurs with mesa-17.3.1.

I haven't checked which commit contributes for its fix. This issue was happening with AMD graphic cards at least, RX460, RX550 and Radeon R7 240.

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.