System Environment: -------------------------- Arch: i386 Platform: Ironlake Libdrm: (master)libdrm-2.4.36 Mesa: (master)1906d2b46b21a8e7496409e0639d8463ad86dcfe Xserver:(master)xorg-server-1.12.0-233-gdae317e7265007b38012244722e3b3a06e904ed5 Xf86_video_intel:(master)2.19.0-344-gdb7979981032d5647069f213a063dcbf78e57890 Libva: (staging)f12f80371fb534e6bbf248586b3c17c298a31f4e Libva_intel_driver:(staging)82fa52510a37ab645daaa3bb7091ff5096a20d0b Kernel: (drm-intel-next-queued) a8b0bbabf756bfb45a712b823ba41f5c95f85589 Bug detailed description: ------------------------------ It aborted on Ironlake, Sandybridge and Ivybridge with mesa master branch.It doesn't happen on mesa 8.0 branch. 'GLSLlinker(negative.varying.beyondMaxVaryingFloats)' and 'max_values(advanced.varyings)' also segfault, and have same bisect commit. Visual Report. ID |ACCELERA|DB |REND_T |SURF_T |C_BUF_T |BUF_S |RED_S | 122| 1| 1| gl| wipbpx| rgba| 32| 8| GREEN_S |BLUE_S |ALPHA_S |DEPTH_S |STENC_S |ACCUM_S |SPL_BUF |SAMPLES | 8| 8| 8| 24| 8| 64| 0| 0| SRGB |TEX_RGB |TEX_RGBA|CAVEAT |SWAP |M_PBUF_W|M_PBUF_H|M_PBUF_P -1| 0| 0| slow| undef| 0| 0| 0 Bisect shows: 8fb1e4a4628caee9e80dcbc47f8f9c772db09419 is the first bad commit. commit 8fb1e4a4628caee9e80dcbc47f8f9c772db09419 Author: Brian Paul <brianp@vmware.com> AuthorDate: Tue Jun 26 13:06:47 2012 -0600 Commit: Brian Paul <brianp@vmware.com> CommitDate: Wed Jun 27 11:31:16 2012 -0600 glsl: be more careful about counting varying vars in the linker Previously, we were counting gl_FrontFacing, gl_FragCoord and gl_PointCoord against the limit of varying variables. This prevented some valid shaders from linking. The other potential solution to this is to have the driver advertise more varying vars or set the GLSLSkipStrictMaxVaryingLimitCheck flag. But the above-mentioned variables aren't conventional varying attributes so it doesn't seem right to count them. Reviewed-by: Eric Anholt <eric@anholt.net> Reproduce steps: ---------------------------- 1. start x 2. ./oglconform -z -suite all -v 2 -D 122 -test GLSLlinker \ volume.varying.32floats
Can you post a stack trace for the segfault/crash?
Backtrace: #0 0x000000000124fc7b in FbConfig::FbConfig(Display_ const&, int, FbConfig::fbconfig_type_t) () #1 0x0000000001268f7b in ScheduleManager::one_format(Display_ const&, int) () #2 0x0000000001215b92 in tkShellExecute(std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&, std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&) () #3 0x00000000004257b5 in main ()
That backtrace doesn't appear to have anything to do with the GLSL linker. Are you sure it's right?
Backtrace: #0 0x00000039266362a5 in raise () from /lib64/libc.so.6 #1 0x0000003926637bbb in abort () from /lib64/libc.so.6 #2 0x000000392667b8fd in __malloc_assert () from /lib64/libc.so.6 #3 0x000000392667ed94 in _int_malloc () from /lib64/libc.so.6 #4 0x00000039266819b5 in calloc () from /lib64/libc.so.6 #5 0x00007ffff64fdce7 in ralloc_size (ctx=0x2b37c60, size=<optimized out>) at ./../../glsl/ralloc.c:117 #6 0x00007ffff648ff09 in ra_alloc_interference_graph (regs=<optimized out>, count=73) at ./../program/register_allocate.c:318 #7 0x00007ffff6933f04 in brw::vec4_visitor::reg_allocate (this=0x7ffffffb04d0) at brw_vec4_reg_allocate.cpp:188 #8 0x00007ffff6932fe0 in brw::vec4_visitor::run (this=0x7ffffffb04d0) at brw_vec4_emit.cpp:807 #9 0x00007ffff693306a in brw::brw_vs_emit (prog=0x2a48940, c=0x7ffffffb8eb0) at brw_vec4_emit.cpp:1035 #10 0x00007ffff68eb5b7 in do_vs_prog (brw=0x274a710, prog=0x2a48940, vp=0x2b85410, key=<optimized out>) at brw_vs.c:242 #11 0x00007ffff68ebd58 in brw_vs_precompile (ctx=0x274a710, prog=<optimized out>) at brw_vs.c:397 #12 0x00007ffff692fe55 in brw_link_shader (ctx=0x274a710, shProg=0x2a48940) at brw_shader.cpp:236 #13 0x00007ffff64f601a in _mesa_glsl_link_shader (ctx=0x274a710, prog=0x2a48940) at ./../program/ir_to_mesa.cpp:3153 #14 0x00007ffff63e9c6c in link_program (ctx=0x274a710, program=<optimized out>) at ./../main/shaderapi.c:712 #15 0x00000000007bc025 in LinkAProgramObject(unsigned int) () #16 0x00000000006647b8 in conform::(anonymous namespace)::TestCaseTemplate::SimpleFunctionCallTest(conform::(anonymous namespace)::TestCaseTemplate::GLSLLinkerTestContext*) () #17 0x0000000000632a4d in conform::(anonymous namespace)::TestCaseTemplate::Run() () #18 0x000000000134b96f in conform::SubcaseBase::RunSubcase(boost::shared_ptr<conform::SubcaseBase> (*)()) () #19 0x000000000134c088 in conform::ExecuteTest(testParameters*, conform::TestInfoBase&, conform::TestCaseInfo const*, unsigned long) () #20 0x000000000065bf3d in GLSLLinkerExec(testParameters*) () #21 0x000000000129b229 in callFunctionHandleExceptionsInner(long (*)(testParameters*), testParameters*, char*) () #22 0x000000000129b37f in callFunctionHandleExceptions(long (*)(testParameters*), testParameters*) () #23 0x000000000129a011 in DriverExec(long (*)(testParameters*), testParameters*) () #24 0x0000000001277095 in Driver(std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&, std::vector<driverRec*, std::allocator<driverRec*> > const&, std::vector<boost::shared_ptr<PrePostTestAction>, std::allocator<boost::shared_ptr<PrePostTestAction> > > const&, std::vector<boost::shared_ptr<PrePostTestcaseAction>, std::allocator<boost::shared_ptr<PrePostTestcaseAction> > > const&) () #25 0x0000000001277818 in (anonymous namespace)::MyMessagePump::idle() () #26 0x0000000001248d10 in MessagePump::process_messages() () #27 0x00000000012760f0 in ExecutionManager::execute_schedules() () #28 0x0000000001218a4f in tkShellExecute(std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&, std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&) () #29 0x00000000004257e5 in main ()
GLSLlinker(negative.varying.beyondMaxVaryingFloats) fails on pineview with mesa master branch, and has same bisect result.
According to Valgrind, we're stomping past the end of fprog->InterpQualifier array in ir_set_program_inouts.cpp:92. This probably cascades leading to a crash. I imagine this is because we don't yet support varying packing. But I could be wrong.
Looks like the mark() function could use a couple assertions. 1. assert(var->location + var->index + offset + i) < 64 at line 87 2. assert(var->location + var->index + offset + i) < Elements( fprog->InterpQualifier) at line 92.
It also happens on mesa 9.0 branch(commit:6886da783ac).
Fix incoming to mailing list.
commit 94e82b2e6cabd7ad26ff35067f6b6675168649d3 Author: Eric Anholt <eric@anholt.net> Date: Tue Nov 13 14:40:22 2012 -0800 mesa: Fix linker-assigned varying component counting since 8fb1e4a462
Fixed on master branch,It has error: shader uses too many varying components (112 > 64). I will close it when this patch cherry pick to 9.0 branch.
Eric, if you confirm no plan for cherry-picking to 9.0 or 9.1, I'll ask Hua to close this.
Verified.Fixed.
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.