Am 11.02.2016 um 01:47 schrieb Vinson Lee: > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94088 > Signed-off-by: Vinson Lee <v...@freedesktop.org> > --- > src/gallium/drivers/llvmpipe/lp_rast.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c > b/src/gallium/drivers/llvmpipe/lp_rast.c > index d22e507..9e56c96 100644 > --- a/src/gallium/drivers/llvmpipe/lp_rast.c > +++ b/src/gallium/drivers/llvmpipe/lp_rast.c > @@ -910,7 +910,9 @@ lp_rast_create( unsigned num_threads ) > create_rast_threads(rast); > > /* for synchronizing rasterization threads */ > - pipe_barrier_init( &rast->barrier, rast->num_threads ); > + if (rast->num_threads > 0) { > + pipe_barrier_init( &rast->barrier, rast->num_threads ); > + } > > memset(lp_dummy_tile, 0, sizeof lp_dummy_tile); > > @@ -967,7 +969,9 @@ void lp_rast_destroy( struct lp_rasterizer *rast ) > } > > /* for synchronizing rasterization threads */ > - pipe_barrier_destroy( &rast->barrier ); > + if (rast->num_threads > 0) { > + pipe_barrier_destroy( &rast->barrier ); > + } > > lp_scene_queue_destroy(rast->full_scenes); > >
Oh good find. I am wondering why it worked before - barriers with 0 count were never legal, and it looks like the glibc implementation would always have returned an error on creation (thus using some uninitialized data when calling destroy). In any case, Reviewed-by: Roland Scheidegger <srol...@vmware.com> I think this should also go to stable. Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
