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.
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.
None of the builds were with LLVM enabled. Interestingly I can't reproduce this on sparc64 which requires strict alignment.
(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?
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.