The following tests ES3-CTS.functional.shaders.constants.uint_ul_suffix_vertex ES3-CTS.functional.shaders.constants.uint_ul_suffix_fragment ES3-CTS.functional.shaders.constants.int_l_suffix_vertex ES3-CTS.functional.shaders.constants.int_l_suffix_fragment trigger this assertion failure: ralloc.c:84: get_header: Assertion `info->canary == 0x5A1106' failed. I bisected this to: $ git bisect bad cc6aa1d161280f10ded7834d1ec2413bc97589fe is the first bad commit commit cc6aa1d161280f10ded7834d1ec2413bc97589fe Author: Timothy Arceri <timothy.arceri@collabora.com> Date: Thu Nov 3 09:18:17 2016 +1100 st/mesa/r200/i915/i965: use rzalloc() to create gl_program This allows us to use ralloc_parent() to see which data structure owns shader_info which allows us to fix a regression in nir_sweep(). This will also allow us to move some fields from gl_linked_shader to gl_program, which will allow us to do some clean-ups like storing gl_program directly in the CurrentProgram array in gl_pipeline_object enabling some small validation optimisations at draw time. Also it is error prone to depend on the gl_linked_shader for programs in current use because a failed linking attempt will free infomation about the current program. In i965 we could be trying to recompile a shader variant but may have lost some required fields. Reviewed-by: Eric Anholt <eric@anholt.net> :040000 040000 7675c88ab61c0f0829fbfd0b983d387f1e8e1344 fbf9bb67a3ac1a3e31487cd493acdb70a413ca44 M src Backtrace: (gdb) bt #0 0x00007ffff61faa28 in raise () from /lib64/libc.so.6 #1 0x00007ffff61fc62a in abort () from /lib64/libc.so.6 #2 0x00007ffff61f3227 in __assert_fail_base () from /lib64/libc.so.6 #3 0x00007ffff61f32d2 in __assert_fail () from /lib64/libc.so.6 #4 0x00007ffff3e5bc18 in get_header (ptr=0x3807d50) at ralloc.c:84 #5 0x00007ffff3e5c037 in ralloc_free (ptr=0x3807d50) at ralloc.c:229 #6 0x00007ffff3d7ee3c in _mesa_delete_program (ctx=0x7ffff7f9b040, prog=0x3807d50) at program/program.c:265 #7 0x00007ffff3f48da3 in brwDeleteProgram (ctx=0x7ffff7f9b040, prog=0x3807d50) at brw_program.c:175 #8 0x00007ffff3d7f05f in _mesa_reference_program_ (ctx=0x7ffff7f9b040, ptr=0x380c358, prog=0x0) at program/program.c:321 #9 0x00007ffff3bfa765 in _mesa_reference_program (ctx=0x7ffff7f9b040, ptr=0x380c358, prog=0x0) at ./program/program.h:89 #10 0x00007ffff3bfa9e4 in _mesa_delete_linked_shader (ctx=0x7ffff7f9b040, sh=0x380c350) at main/shaderobj.c:152 #11 0x00007ffff3bfb177 in _mesa_free_shader_program_data (ctx=0x7ffff7f9b040, shProg=0x37db160) at main/shaderobj.c:391 #12 0x00007ffff3bfb1d7 in _mesa_delete_shader_program (ctx=0x7ffff7f9b040, shProg=0x37db160) at main/shaderobj.c:408 #13 0x00007ffff3bfac1c in _mesa_reference_shader_program_ (ctx=0x7ffff7f9b040, ptr=0x380e2e0, shProg=0x0) at main/shaderobj.c:239 #14 0x00007ffff3d710ac in _mesa_reference_shader_program (ctx=0x7ffff7f9b040, ptr=0x380e2e0, shProg=0x0) at ./main/shaderobj.h:75 #15 0x00007ffff3d7131f in clear_cache (ctx=0x7ffff7f9b040, cache=0x37afe40, shader=1 '\001') at program/prog_cache.c:122 #16 0x00007ffff3d71472 in _mesa_delete_shader_cache (ctx=0x7ffff7f9b040, cache=0x37afe40) at program/prog_cache.c:168 #17 0x00007ffff3d7e9de in _mesa_free_program_data (ctx=0x7ffff7f9b040) at program/program.c:118 #18 0x00007ffff3ac044b in _mesa_free_context_data (ctx=0x7ffff7f9b040) at main/context.c:1320 #19 0x00007ffff3f31255 in intelDestroyContext (driContextPriv=0x3727d60) at brw_context.c:1200 #20 0x00007ffff3f15e0a in driDestroyContext (pcp=0x3727d60) at dri_util.c:500 #21 0x00007ffff6e381ce in dri2_destroy_context (drv=0x3685170, disp=0x3685440, ctx=0x37a57f0) at drivers/dri2/egl_dri2.c:1242 #22 0x00007ffff6e2afd6 in eglDestroyContext (dpy=0x3685440, ctx=0x37a57f0) at main/eglapi.c:764 #23 0x00000000028f043d in eglw::FuncPtrLibrary::destroyContext(void*, void*) const () #24 0x00000000027b0379 in eglu::(anonymous namespace)::RenderContext::destroy() () #25 0x00000000027aee89 in eglu::(anonymous namespace)::RenderContext::~RenderContext() () #26 0x00000000027aefb8 in eglu::(anonymous namespace)::RenderContext::~RenderContext() () #27 0x00000000027582cc in deqp::Context::destroyRenderContext() () #28 0x00000000027580f4 in deqp::Context::~Context() () #29 0x00000000027901be in deqp::PackageContext::~PackageContext() () #30 0x00000000027903e0 in deqp::TestPackage::deinit() () #31 0x00000000028b0cd9 in tcu::DefaultHierarchyInflater::leaveTestPackage(tcu::TestPackage*) () #32 0x00000000028b1585 in tcu::TestHierarchyIterator::next() () #33 0x000000000286fdf5 in tcu::TestSessionExecutor::iterate() () #34 0x0000000002844d09 in tcu::App::iterate() () #35 0x0000000000e72914 in main ()
fixed by 979ec2cf754b28640c1c03a5cae8cc3a5febf33e i965: use rzalloc instead of calloc in brwNewProgram commit cc6aa1d161280f10ded7834d1ec2413bc97589fe changed to using rzalloc for gl_program creation but one instance for program creation was still using calloc.
*** Bug 98595 has been marked as a duplicate of this bug. ***
979ec2cf754b28640c1c03a5cae8cc3a5febf33e does not fix the problem mentioned in 98595, as mentioned there I encountered it with 0c17b0b6f089e325de6a3f871c8d799326be4202 which is a later revision (and at the time of writing still the latest).
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.