Skip to content

vrend: Check whether a shader type actually exisits before uploading constants

When changing the from a one-by-one upload to an array upload the test for the array pointer to the uniform IDs was replaced by testing the uniform array ID against -1. However, this is not enough, because when the context is allocated all is cleared to zero, and apparently the structure is re-used in different invocations of shader programs. Here, one shader might have been removed but the const field was still allocated resulting in a sigsegv. This happens e.g. by running

dEQP-GLES31.functional.primitive_bounding_box.wide_points. global_state.vertex_tessellation_geometry_fragment.fbo_bbox_larger global_state.vertex_tessellation_geometry_fragment.fbo_bbox_smaller tessellation_set_per_draw.vertex_tessellation_fragment.default_framebuffer_bbox_equal tessellation_set_per_draw.vertex_tessellation_fragment.default_framebuffer_bbox_larger

resulting in AddressSanitizer: SEGV on unknown address 0x00000000001c The signal is caused by a READ memory access. Hint: address points to the zero page. #0 0x7f595b9eb875 in vrend_draw_bind_const_shader src/vrend_renderer.c:3677 #1 (closed) 0x7f595b9ed37f in vrend_draw_bind_objects src/vrend_renderer.c:3810

Work around this by checking whether the shader type data is allocated.

Fixes: 172c9679 vrend/shader: handle uniforms as array

-- This is probably more of a hotfix, the question is whether we want to keep the constant pointer when the used shader set changes. On one hand freeing it always would make the code cleaner, on the other hand keeping it could save us some mallocs, but with my changes the size of the allocated array will stay at the maximum ever used.

Merge request reports