Created atta=
chment 129030 [details]
gdb script to verify use after free
Our application enables and disables GL_POLYGON_OFFSET_FILL multiple times =
per
frame, and it has been crashing on Ubuntu 16.04. (We are aware that our usa=
ge
pattern is probably not ideal.) We believe the crash is occurring because t=
he
radeonsi driver is using the memory pointed to by
si_context->queued.named.poly_offset after it has been freed.
We have verified the use after free behavior by running the attached gdb sc=
ript
against the master branch (commit 1e1bddf15a1720917b11e44dc639351ad613c3dc).
Unfortunately we are not yet able to provide a sample application to run th=
is
against.
The following scenario may not be completely accurate, but hopefully it sho=
uld
give a feel for the sequence of events leading up to this issue:
glEnable(GL_POLYGON_OFFSET_FILL)
* sets pipe_rasterizer_state->offset_tri to true
si_create_rs_state
* callocs rasterizer A
* sets A->uses_poly_offset to true because pipe_rasterizer_state->o=
ffset_tri
is true
si_bind_rs_state
* changes si_context->queued.named.rasterizer to rasterizer A
* calls si_update_poly_offset_state to make queued.named.poly_offset point
into rasterizer A
glDisable(GL_POLYGON_OFFSET_FILL)
* sets pipe_rasterizer_state->offset_tri to false
si_create_rs_state
* callocs rasterizer B
* sets B->uses_poly_offset to false because pipe_rasterizer_state->=
offset_tri
is false
si_bind_rs_state
* changes the rasterizer to rasterizer B
* calls si_update_poly_offset_state to make sure poly_offset is up to date
* si_update_poly_offset_state
* sets rs to si_context.queued.named.rasterizer, which is B
* returns without updating poly_offset because B->uses_poly_offset=
is
false
* poly_offset still points into rasterizer A
si_delete_rs_state
* does NOT set poly_offset to NULL because queued.named.rasterizer no lon=
ger
points to rasterizer A
* frees rasterizer A via si_pm4_delete_state
si_draw_vbo
* calls si_pm4_emit_dirty
* follows poly_offset into rasterizer A, which has been freed
* bad things happen
The patch attached below ensures si_update_poly_offset sets poly_offset to =
NULL
if uses_poly_offset is false. We think this makes sense because it always
leaves poly_offset in a valid state. Either it points into the currently qu=
eued
rasterizer, or it is NULL. If this does turn out to be the correct fix, the
attempt to NULL poly_offset from si_delete_rs_state should probably be remo=
ved
as well.
Thanks!