Bug 98592 - [bisected] "Assertion `info->canary == 0x5A1106' failed." in several GLES3 conformance tests
Summary: [bisected] "Assertion `info->canary == 0x5A1106' failed." in several GLES3 co...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-04 17:29 UTC by Ian Romanick
Modified: 2016-11-05 13:11 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Ian Romanick 2016-11-04 17:29:39 UTC
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 ()
Comment 1 Mark Janes 2016-11-04 17:41:09 UTC
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.
Comment 2 Timothy Arceri 2016-11-05 07:30:01 UTC
*** Bug 98595 has been marked as a duplicate of this bug. ***
Comment 3 Jonathan Gray 2016-11-05 13:11:18 UTC
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.