Bug 95395 - glsl: NULL type value in add_uniform() leads to SIGSEGV
Summary: glsl: NULL type value in add_uniform() leads to SIGSEGV
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: 11.2
Hardware: ARM OpenBSD
: medium normal
Assignee: mesa-dev
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-14 07:17 UTC by Jonathan Gray
Modified: 2016-05-18 03:04 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
glxinfo from the arm machine (19.90 KB, text/plain)
2016-05-14 07:17 UTC, Jonathan Gray
Details

Description Jonathan Gray 2016-05-14 07:17:28 UTC
Created attachment 123737 [details]
glxinfo from the arm machine

When running glxgears with Mesa 11.2.2 over X11 forwarding with the gallium softpipe renderer on OpenBSD arm I see the following crash.

Program received signal SIGSEGV, Segmentation fault.
add_uniform (this=Variable "this" is not available.) at /usr/xenocara/lib/mesa/src/compiler/glsl/builtin_variables.cpp:544
544        const unsigned array_count = type->is_array() ? type->length : 1;
Current language:  auto; currently c++
(gdb) bt
#0  add_uniform (this=Variable "this" is not available.) at /usr/xenocara/lib/mesa/src/compiler/glsl/builtin_variables.cpp:544
#1  0x453d97ec in generate_uniforms (this=0xbfff1508) at /usr/xenocara/lib/mesa/src/compiler/glsl/builtin_variables.cpp:882
#2  0x453db110 in _mesa_glsl_initialize_variables (instructions=Variable "instructions" is not available.
) at /usr/xenocara/lib/mesa/src/compiler/glsl/builtin_variables.cpp:1304
#3  0x451ec5e4 in _mesa_get_fixed_func_fragment_program (ctx=0x40246000) at /usr/xenocara/lib/mesa/src/mesa/main/ff_fragment_shader.cpp:1225
#4  0x4529d038 in _mesa_update_state_locked () at glsl_symbol_table.h:45
#5  0x4529d1b0 in _mesa_update_state () at glsl_symbol_table.h:45
#6  0x451b8268 in _mesa_Clear () at nir_builder_opcodes.h:80
#7  0x469e3e30 in glClear () from /usr/X11R6/lib/libGL.so.17.0
#8  0x0000a998 in __register_frame_info ()
#9  0xbfff1a80 in ?? ()
Cannot access memory at address 0x34388d3f
(gdb) p type
$1 = (const glsl_type *) 0x0
(gdb) p name
$2 = 0x4558e6fc "gl_CurrentAttribVertMESA"

I can't reproduce this on amd64 forcing softpipe via LIBGL_ALWAYS_SOFTWARE, which leads me to believe this is somehow alignment related.
Comment 1 Ilia Mirkin 2016-05-14 18:42:50 UTC
Another thing to check is whether you can reproduce on amd64 with DRAW_USE_LLVM=0 - otherwise softpipe uses llvm for the vertex stages when available.
Comment 2 Jonathan Gray 2016-05-15 02:31:29 UTC
None of the builds were with LLVM enabled.  Interestingly I can't reproduce this on sparc64 which requires strict alignment.
Comment 3 Ilia Mirkin 2016-05-16 15:02:17 UTC
(In reply to Jonathan Gray from comment #0)
> Created attachment 123737 [details]
> glxinfo from the arm machine
> 
> When running glxgears with Mesa 11.2.2 over X11 forwarding with the gallium
> softpipe renderer on OpenBSD arm I see the following crash.
> 
> Program received signal SIGSEGV, Segmentation fault.
> add_uniform (this=Variable "this" is not available.) at
> /usr/xenocara/lib/mesa/src/compiler/glsl/builtin_variables.cpp:544
> 544        const unsigned array_count = type->is_array() ? type->length : 1;
> Current language:  auto; currently c++
> (gdb) bt
> #0  add_uniform (this=Variable "this" is not available.) at
> /usr/xenocara/lib/mesa/src/compiler/glsl/builtin_variables.cpp:544
> #1  0x453d97ec in generate_uniforms (this=0xbfff1508) at
> /usr/xenocara/lib/mesa/src/compiler/glsl/builtin_variables.cpp:882
> #2  0x453db110 in _mesa_glsl_initialize_variables (instructions=Variable
> "instructions" is not available.
> ) at /usr/xenocara/lib/mesa/src/compiler/glsl/builtin_variables.cpp:1304
> #3  0x451ec5e4 in _mesa_get_fixed_func_fragment_program (ctx=0x40246000) at
> /usr/xenocara/lib/mesa/src/mesa/main/ff_fragment_shader.cpp:1225
> #4  0x4529d038 in _mesa_update_state_locked () at glsl_symbol_table.h:45
> #5  0x4529d1b0 in _mesa_update_state () at glsl_symbol_table.h:45
> #6  0x451b8268 in _mesa_Clear () at nir_builder_opcodes.h:80
> #7  0x469e3e30 in glClear () from /usr/X11R6/lib/libGL.so.17.0
> #8  0x0000a998 in __register_frame_info ()
> #9  0xbfff1a80 in ?? ()
> Cannot access memory at address 0x34388d3f
> (gdb) p type
> $1 = (const glsl_type *) 0x0
> (gdb) p name
> $2 = 0x4558e6fc "gl_CurrentAttribVertMESA"
> 
> I can't reproduce this on amd64 forcing softpipe via LIBGL_ALWAYS_SOFTWARE,
> which leads me to believe this is somehow alignment related.

OK, so somehow...

   add_uniform(array(vec4_t, VERT_ATTRIB_MAX), "gl_CurrentAttribVertMESA");

is ending up with a null for the GLSL type.

   const glsl_type *array(const glsl_type *base, unsigned elements)
   {
      return glsl_type::get_array_instance(base, elements);

And if you look at glsl_type::get_array_instance, it creates these things on demand and sticks them into a hash table. Perhaps the hash table is broken on arm? Or perhaps your compiler is broken on arm? If you're building this with clang, can you check if the issue persists with gcc?
Comment 4 Jonathan Gray 2016-05-18 03:04:44 UTC
Indeed it seems to be a compiler bug of some sort.  I encountered it with the system compiler (based on gcc 4.2.1).  After building gcc 4.9.3 and building Mesa with that I can't reproduce this problem.  Sorry for the noise I'll close this as it isn't a Mesa issue.


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.